> One major problem (besides the readability/optimize problems) with this
> approach was that all conditions (also "Join conditions") are applied to the
> WHERE clause. Some databases react with bad performance on such
> SQL-statements, others "auto-optimize" them quietly.
That's what I thought too, about the bad performance. View entities (dynamic or otherwise) in
OFBiz do not allow for "join conditions" (eg join table_a on "some condition").
See a thread I created at
http://www.nabble.com/forum/ViewPost.jtp?post=12018323&framed=y .
Jonathon
Eilebrecht, Karl (Key-Work) wrote:
The issue "JIRA-1033 Ofbiz SQL Integration Features"
might be interesting for your discussion.
Maybe this is a basis for supporting multiple ways to solve common problems
(RDBMS *dependent* (much better to debug and optimize) vs. RDBMS-independent
"HQL-like").
Remark: in 2005/06 we first tried to solve our query problems by heavily using Dynamic View Entities. One
major problem (besides the readability/optimize problems) with this approach was that all conditions (also
"Join conditions") are applied to the WHERE clause. Some databases react with bad performance on
such SQL-statements, others "auto-optimize" them quietly. However, I think it's a good idea (when
reworking the entity engine) to enhance the ability to have join conditions as a part of the view entities'
"metadata".
Regards.
Karl
-----Ursprüngliche Nachricht-----
Von: Jonathon -- Improov [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 22. Oktober 2007 05:30
An: [email protected]
Betreff: Re: ofbiz sql
I've read a similar thread (and possibly responded to it).
I vote for it. The point is to be able to programmatically generate queries to the Entity Engine.
Using raw SQL will of course be RDBMS-dependent. Using an OFBiz SQL dialect will be RDBMS-independent.
That's what little I remember from the thread I read and/or responded to.
Jonathon
Adam Heath wrote:
Jacques Le Roux wrote:
Was not delegator methods thought to hide SQL code ? I think that David meant
to prune not to replace. In both case such a changes
implie
major tedious refactoring. Though using deprecated concept it could be carried
on carefully in time...
I don't think you understand.
You wouldn't be writing sql to the raw jdbc. You'd be writing an Ofbiz
sql dialect. Ofbiz would then translate that on the fly to the correct
underlying form.
Besuchen Sie uns:
- Mail Order World in Wiesbaden vom 24.-25.10.2007
Halle 5, Stand 510
http://www.key-work.de/mow
- Effizienztag Mode/Modehandels-Kongress
in Düsseldorf vom 7.11.-8.11.2007, Stand 16
http://www.key-work.de/mhk
- IMB-Forum in Köln vom 21.-22.11.2007
Halle 08, Stand Boulevard Gang A Nr. 29
http://www.key-work.de/imb
