cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <...@maniatis.org>
Subject Re: New features in Select API
Date Wed, 08 Apr 2015 01:24:25 GMT
On 7/04/2015 9:13pm, Savva Kolbachev wrote:
> Hi All! It's a pleasure for me to introduce to you some new features in
> Select API. I'd be thrilled if you could have a look and give us your
> feedback.

Nice work.



> This method selects a single object regardless of how many objects are
> matched by query. This makes 'selectFirst' different from ‘selectOne’,
> which would throw exception in this situation. ‘selectFirst’ is useful e.g.
> when the query is ordered and we only want to see the first object (e.g.
> "most recent news article"):

It seems like quite a bit of clutter to have:

query.limit(1).select(context)
query.selectOne(context)
query.selectFirst(context)
query.requireOne(context)  (Michael's suggestion)

That's a lot of function calls that people are going to get mixed up, with only a bunch of
different exceptions separating them. How about we reduce that to two:

query.selectFirst(context)  -> no exceptions even if there are zero or >1 records
query.selectOne(context) -> exception if there are zero or >1 records

That would require that internally, the second function needs to generate LIMIT 2 in the SQL,
in order to catch that second exception. So perhaps that has a small performance penalty.


> // Add ordering
> 
> query.addOrdering(new Ordering(Article.PUBLISHED.getName()));

Can we have a shorter syntax for this as well (for a typical use case):

query.addOrdering(Article.PUBLISHED);



> // Select most recent news article
> 
> Article article = query.selectFirst(context);
> 
> Selecting the first object via "Select.selectFirst(ObjectContext)" is more
> comprehensible than selecting via "ObjectContext.selectFirst(Select)",
> because implementations of "Select" usually set fetch size limit to one.
> 
> 3. I’ve added ResultBatchIterator which allows iterating through results by
> micro-batches. For example:


Although it looks really cool, I worry that this is taking us too far away from Cayenne's
true purpose. Personally I'm -1 on all the iterator methods. There are plenty of libraries
that already do all that, and probably better than us (more choices, flexibility, users, testing).

http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Lists.html#partition%28java.util.List,%20int%29

https://commons.apache.org/proper/commons-collections/javadocs/api-3.2.1/index.html?org/apache/commons/collections/IteratorUtils.html


Am I missing the point here of why these should be in an ORM? Personally if we are going to
add more convenience functions I'd rather see query.count(), query.sum(Article.PRICE), etc
aggregate functions.


Cheers
Ari




-- 
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Mime
View raw message