Mmm, I'm suddenly wondering if we should not care about the changes recently introduced throughout the framework.
Karl could you please create a new patch using current trunk ? Thanks in advance Jacques > 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 > > > > > > >
