OFBiz › OFBiz - Dev

ofbiz sql

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

18 messages Options

Adam Heath-2

ofbiz sql

David mentioned recently that the delegator has quite a number of
methods in it; this can be daunting to new users.

If it could handle sql natively, then this could be reduced.

EntityCondition condition = new EntityConditionList(
UtilMisc.toList(
new EntityExpr("firstName", EntityOperator.LIKE, "%Adam%"),
new EntityExpr("lastName", EntityOperator.LIKE, "%Heath%")
),
EntityOperator.AND
);
List people = delegator.findByConditionCache("Person", condition, null,
UtilMisc.toList("firstName", "lastName"));

... or ....

Query query = delegator.compileSql("SELECT * FROM Person WHERE firstName
LIKE $firstName AND lastName LIKE $lastName ORDER BY firstName, lastName");
query.setParameter("firstName", "%Adam%");
query.setParameter("lastName", "%Heath%");
List people = delegator.runQuery(query);

The compiled query could be cached, or created during an init phase;
this would speed things up. Additionally, views could also be done with
this sql code. And the sql string could be generated by a template;
meaning that whole parts of it might be conditional, using
freemarker/velocity conditions, both on joins, and regular group
by/order by/select fields/conditions.

BJ Freeman

Re: ofbiz sql

there is a sql ability in the webtools
so I am sure that can be implemented in code.

Adam Heath sent the following on 10/18/2007 12:39 AM:

> David mentioned recently that the delegator has quite a number of
> methods in it; this can be daunting to new users.
>
> If it could handle sql natively, then this could be reduced.
>
> EntityCondition condition = new EntityConditionList(
> UtilMisc.toList(
> new EntityExpr("firstName", EntityOperator.LIKE, "%Adam%"),
> new EntityExpr("lastName", EntityOperator.LIKE, "%Heath%")
> ),
> EntityOperator.AND
> );
> List people = delegator.findByConditionCache("Person", condition, null,
> UtilMisc.toList("firstName", "lastName"));
>
> ... or ....
>
> Query query = delegator.compileSql("SELECT * FROM Person WHERE firstName
> LIKE $firstName AND lastName LIKE $lastName ORDER BY firstName, lastName");
> query.setParameter("firstName", "%Adam%");
> query.setParameter("lastName", "%Heath%");
> List people = delegator.runQuery(query);
>
> The compiled query could be cached, or created during an init phase;
> this would speed things up. Additionally, views could also be done with
> this sql code. And the sql string could be generated by a template;
> meaning that whole parts of it might be conditional, using
> freemarker/velocity conditions, both on joins, and regular group
> by/order by/select fields/conditions.
>
>

Adrian Crum

Re: ofbiz sql

In reply to this post by Adam Heath-2

There was some effort a while ago to have the EE support running on an LDAP datastore. How would
this work with a (possible future) LDAP datastore?

Adam Heath wrote:

Adam Heath-2

Re: ofbiz sql

In reply to this post by BJ Freeman

BJ Freeman wrote:
> there is a sql ability in the webtools
> so I am sure that can be implemented in code.

That is not the same thing. That does a *raw* query to jdbc.

What I am talking about, is having the delegator parse the sql string,
do all mappings(entityname -> table name, field name -> column name,
etc), and then do the query.

This would even work for views. For example:

SELECT * FROM PartyContactWithPurpose;

That would be auto-converted to the appropriate real sql code on the
back end. You could also write sql code that does a join inline:

SELECT
a.partyId, a.partyTypeId,
b.firstName, b.lastName,
c.groupName
FROM
Party a LEFT JOIN Person b USING (partyId)
LEFT JOIN PartyGroup c USING (partyId)
;

Jacques Le Roux

Re: ofbiz sql

Administrator

In reply to this post by Adam Heath-2

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 like the idea of replacing the cache avatars by a parameter. It implies a lot of tedious refactoring too...

For the idea below, I like it as enhancement (compiled query being a must) not a replacement, which is a paradox because this
thread was about to prune.

Jacques

PS : I added David's initial message a bottom to not lose the thread
+1 for the "less is more" concept. I guess deprecating is the way, no time to fill the list yet...

De : "David E Jones" <[hidden email]>

>
> This has been discussed before, but I thought it might be a good time
> to bring it up again based on Adam Heath's recent additions to the
> GenericDelegator (in revs r585808, r585803, r585802, r585759).
>
> One of the issue with the Entity Engine that has been getting worse
> over the years is method bloat. There are WAY too many variations of
> different methods, IMO. These have been added for convenience, but
> the net effect (that I don't think was expected or even considered)
> is that when looking at the massive list it is tricky to figure out
> which methods to use for what. This is a big problem for people new
> to the Entity Engine, but also a problem for experienced EE users.
>
> In short lately I'm thinking that having so many methods is worse
> than the convenience they offer to make life easier for "lazy"
> coders. Actually, with a decent IDE having lots of parameters isn't
> such a big deal.
>
> This does have the down side of requiring changes to lots of existing
> code to use the fully featured methods instead of the simplified ones
> (most of which just call the full featured ones with default values).
>
> The up side is we end up with a really happy and clean
> GenericDelegator class with only maybe 10-15 methods for different
> general operations, and perhaps even less than that, like 5-10...
> (aside from the cache maintenance methods, and other utility methods,
> many of which we might want to make private, the general goal being
> to simplify the class).
>
> In shorter I think this is getting to be one of those cases where
> less is more...
>
> Any thoughts? Should we start mass-marking methods as deprecated?
> Which ones and in what forms of the methods should we leave?
>
> -David
>
>

Adam Heath-2

Re: ofbiz sql

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.

Adrian Crum

Re: ofbiz sql

Adam,

That makes it much clearer. In that case, you have my vote.

+1

-Adrian

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.
>

Jacques Le Roux

Re: ofbiz sql

Administrator

In reply to this post by Adam Heath-2

De : "Adam Heath" <[hidden email]>

> 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.

Mmm..., do you think so ?

>
> 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.

In your example the difference is very light !

Jacques

Adam Heath-2

Re: ofbiz sql

Jacques Le Roux wrote:

> De : "Adam Heath" <[hidden email]>
>
>> 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.
>
> Mmm..., do you think so ?
>
>> 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.
>
> In your example the difference is very light !

In OfBiz, you can create views; this has to be done by editing an
entitymodel.xml file. This is more difficult than I care for.

In my new feature(which is not done, and I don't know when I'll get back
to working on it), you can just write sql code that does a join itself.

jonwimp

Re: ofbiz sql

In reply to this post by Adam Heath-2

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.
>
>

jonwimp

Re: ofbiz sql

In reply to this post by Adam Heath-2

> In my new feature(which is not done, and I don't know when I'll get back to
> working on it), you can just write sql code that does a join itself.

If the point is to circumvent entity views, then I would advise against it. I'd rather enhance the
entity view engine.

Being able to declaratively define a view in a consolidated area is great for code organization
and self-evident docs.

Jonathon

Adam Heath wrote:

> Jacques Le Roux wrote:
>> De : "Adam Heath" <[hidden email]>
>>
>>> 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.
>> Mmm..., do you think so ?
>>
>>> 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.
>> In your example the difference is very light !
>
> In OfBiz, you can create views; this has to be done by editing an
> entitymodel.xml file. This is more difficult than I care for.
>
> In my new feature(which is not done, and I don't know when I'll get back
> to working on it), you can just write sql code that does a join itself.
>
>

Jacques Le Roux

Re: ofbiz sql

Administrator

> > In my new feature(which is not done, and I don't know when I'll get back to
> > working on it), you can just write sql code that does a join itself.
>
> If the point is to circumvent entity views, then I would advise against it. I'd rather enhance the
> entity view engine.
>
> Being able to declaratively define a view in a consolidated area is great for code organization
> and self-evident docs.

This is an interesting POV

Thanks Jonathon

Jacques

>
> Jonathon
>
> Adam Heath wrote:
> > Jacques Le Roux wrote:
> >> De : "Adam Heath" <[hidden email]>
> >>
> >>> 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.
> >> Mmm..., do you think so ?
> >>
> >>> 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.
> >> In your example the difference is very light !
> >
> > In OfBiz, you can create views; this has to be done by editing an
> > entitymodel.xml file. This is more difficult than I care for.
> >
> > In my new feature(which is not done, and I don't know when I'll get back
> > to working on it), you can just write sql code that does a join itself.
> >
> >
>

Eilebrecht, Karl (Key-Work)

AW: ofbiz sql

In reply to this post by jonwimp

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:[hidden email]]
Gesendet: Montag, 22. Oktober 2007 05:30
An: [hidden email]
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:

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
[hidden email]

Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
Geschäftsführer: Andreas Stappert, Tobin Wotring

jonwimp

Re: AW: ofbiz sql

> 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:[hidden email]]
> Gesendet: Montag, 22. Oktober 2007 05:30
> An: [hidden email]
> 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
>
>

Jacques Le Roux

Re: ofbiz sql

Administrator

In reply to this post by Eilebrecht, Karl (Key-Work)

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)" <[hidden email]>
> 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:[hidden email]]
> Gesendet: Montag, 22. Oktober 2007 05:30
> An: [hidden email]
> 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
> [hidden email]
>
>
> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
> Geschäftsführer: Andreas Stappert, Tobin Wotring
>
>
>

Jacques Le Roux

Re: ofbiz sql

Administrator

In reply to this post by Adam Heath-2

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)" <[hidden email]>
> > 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:[hidden email]]
> > Gesendet: Montag, 22. Oktober 2007 05:30
> > An: [hidden email]
> > 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
> > [hidden email]
> >
> >
> > Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
> > Geschäftsführer: Andreas Stappert, Tobin Wotring
> >
> >
> >
>

Eilebrecht, Karl (Key-Work)

AW: ofbiz sql

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:[hidden email]]
Gesendet: Freitag, 26. Oktober 2007 15:32
An: [hidden email]
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

it's

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

Jacques Le Roux

Re: ofbiz sql

Administrator

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:[hidden email]]
> Gesendet: Freitag, 26. Oktober 2007 15:32
> An: [hidden email]
> 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)" <[hidden email]>
> > > 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:[hidden email]]
> > > Gesendet: Montag, 22. Oktober 2007 05:30
> > > An: [hidden email]
> > > 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
> > > [hidden email]
> > >
> > >
> > > 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
>
>
>