Re: svn commit: r835637 - in /ofbiz/trunk/framework/entity: build.xml src/org/ofbiz/entity/sql/ src/org/ofbiz/entity/sql/Parser.jjt src/org/ofbiz/entity/sql/SQLSelect.java

[Scott Gray]

On 13/11/2009, at 1:27 PM, Adam Heath wrote:

Scott Gray wrote:

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.

Offset is simple, relatively.  Just need to issue a bunch of rs.next()
calls early, and then a flag to EntityListIterator to forbid calling
rs.previous() past the beginning.

That is a possibility but it wouldn't really achieve much. The main advantage I see to using offset is to avoid the need to stream unneeded results, especially for jdbc drivers that don't support cursors.

I agree view-entity definitions can at times be quite verbose and it

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.

could be useful there in some situations, but will these sql statements

Absolutely.  It's rather trival to extend the parser, to have multiple
selects defined in some global .sql file, giving each a NAME, then
also extending the condition parser to have a ?NAME type syntax.

Maybe using this api(brainstorming):

eli = EntitySql.getListIterator(delegator, "path/to/resource.sql",
"my-special-query", Map<String, Object> params)

What would be cool and what I would use is a tool that is capable of generating a view entity xml definition from a sql query.

smime.p7s
Description: S/MIME cryptographic signature