The problem is that the result type is the actual execution method, the query has to have a way to know when to fire.
Regards Scott On 19/04/2010, at 6:27 PM, Adrian Crum wrote: > Using Entity instead of Query and putting the result type after the entity > name might be more fluent. > > Entity.Product.One.where(Map); > Entity.Product.List.where(Map); > Entity.Product.Iterator.where(Map); > Entity.Product.List.where(EntityCondition).orderBy(String|List); > Entity.Product.List.where(EntityCondition).orderBy(List).useCache(); > > > --- On Sun, 4/18/10, Scott Gray <[email protected]> wrote: > >> From: Scott Gray <[email protected]> >> Subject: Delegator Helper class for groovy? >> To: [email protected] >> Date: Sunday, April 18, 2010, 2:23 PM >> How about we create a new Query class >> that simplifies using the DelegatorInterface? >> Mostly for groovy but we could use it in java as well: >> Query.Product.where(Map).one(); >> Query.Product.where(Map).list(); >> Query.Product.where(Map).iterator(); >> Query.Product.where(EntityCondition).orderBy(String|List).list(); >> Query.Product.where(EntityCondition).orderBy(List).useCache().list(); >> Query.Product.where(EntityCondition).having(EntityCondition).orderBy(String).useCache() >> >> Query.new()."Product".where(expr).orderBy("productId").useCache().list(); >> >> Basically you start with Query.<EntityName> and >> finish with one(), list() or iterator() >> Every method except for those last 3 return the Query >> object so you can continue to build it out by chaining >> method calls. >> >> Query building methods: >> where(Map | EntityCondition) >> having(Map | EntityCondition) >> orderBy(String | Collection<String>) >> useCache() >> range(Integer start, Integer size) >> range(Integer size) >> >> Should cover most of the use cases and I think it would be >> more intuitive than trying to deal with the delegator's huge >> API. Any thoughts? >> >> Thanks >> Scott >> >> HotWax Media >> http://www.hotwaxmedia.com >> >> > > >
smime.p7s
Description: S/MIME cryptographic signature
