On 13/11/2009, at 1:10 PM, Adam Heath wrote:
Scott Gray wrote:I'd be careful with the limit/offset, support tends to vary among vendors, e.g. http://blogs.sun.com/kah/entry/derby_10_5_preview_fetchYou are mistaken. This does *not* send raw sql to the database. It parses the sql into a DynamicViewEntity, which ofbiz then reconverts back to whatever sql dialect is required by the underlying database. Offset/limit can be completely handled in java. Besides, I currently don't have them fully implemented. And EntityFindOptions has a maxRows option.
I could see that it doesn't send the raw sql to the database I was just trying to point out that offset isn't currently supported by the entity engine and that adding support for it could be problematic.
I like the concept, but to be honest I have to deal with raw sql so rarely these days that given the choice I probably wouldn't use it.Which is easier; editting a <view-entity> xml definition, or creating a sql string? Consider the case when you have option parts of a query you have to deal with. In addition, I'll be adding helper methods to parse *just* entityconditions. It's mostly there, I just haven't made the methods public.
I agree view-entity definitions can at times be quite verbose and it could be useful there in some situations, but will these sql statements be reusable in the same way that view entities are? Also I actually like the java-ness of constructing dynamic view entities rather that building a string, it makes the code easier to read IMO.
smime.p7s
Description: S/MIME cryptographic signature
