Hi Karl, I have just read you document, very interesting. I would like to integrate your work in OFBiz. It's well documented and a must when it comes to optimise performances. My primarily intention is hence to integrate not as a subsititure in any way (this is clearly explained in the documentation) but as an option when you need more SQL power and control.
Of course everybody using it should be aware of the main limitation : no ECAs are fired ! Other limitations or warning are cleary underlined (I like icons you used like in a professionnal doc. ;o) in the documentation. If nobody complains I will commit in some days Thanks Jacques De : "Eilebrecht, Karl (Key-Work)" <[EMAIL PROTECTED]> > 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: dev@ofbiz.apache.org > 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 > > > -- > Karl Eilebrecht > Key-Work Consulting GmbH > > Kriegsstr. 100 - 76133 Karlsruhe - Germany > Fon: +49-721-78203-277 - Fax: +49-721-78203-10 > [EMAIL PROTECTED] > > > Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim > Geschäftsführer: Andreas Stappert, Tobin Wotring > > >
