Hi Karl, Thanks for the input. Anyway in the meantime if someone is interested he/her can always use your work with a pre-framework-recent-changes version. Actually it may even work with framework changed, I did not test.
Thanks Jacques > Hi Jacques, > > it is nice to read that you like the approach and the documentation > (JIRA-1033). > But I think I must disappoint you. > > Last year I could convince our management to invest > a lot of time in ofbiz. In April 2007 I opened several > well documented issues with patches. That time David wanted > to review them or to find other ofbiz inner circle developers > to do that. I think, he didn't find the time or what ever. > > Since then our company didn't update the ofbiz installation, so > I just can't provide any newer patches. > Maybe (I'm not sure) we're upgrading on a new ofbiz version > in spring 2008. > > Current project situation doesn't allow me to do the > work of last April again this time, sorry for that. > > Regards. > Karl > > > > > -----Ursprüngliche Nachricht----- > Von: Jacques Le Roux [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 26. Oktober 2007 15:32 > An: dev@ofbiz.apache.org > Betreff: Re: ofbiz sql > > 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 > > > > > > > > > > > > > > Besuchen Sie uns: > > - 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 > > >
