use of org.ofbiz.entity.condition.EntityClause

[Adam Heath <do...@brainfood.com>]

I find no users of the above class anywhere in ofbiz.  I've searched
the existing repository, and the previous one hosted on
svn.ofbiz.org(still there).  I see no reason for that file to exist,
and would like to remove it.

I can guess what it might be used for, as a way to stitch random
entities together in a generated sql string, that are not actually
part of the parent query.  It's been relatively unchanged since Andrew
did a test merge from a branch(doesn't say what) on Feb 22, 2005.

Re: use of org.ofbiz.entity.condition.EntityClause

[Bob Morley <rm...@emforium.com>]

Adam Heath-2 wrote:
> 
> Adam Heath wrote:
>> David E Jones wrote:
>>> If this was removed, what would people who use this now use instead?
>> 
>> Nothing in ofbiz uses this class.  None of the sql generating code
>> makes use of this class.  It literally is completely orphaned.
>> 
>> How is this class used to query the database?
>> 
>> Plus, look at EntityWhereString, which is close to EntityClause.
> 
> Replying to myself replying to David...
> 
> If this class really is used outside of ofbiz, then how is that done?
>  Is there an example somewhere of how to do it?
> 

It really looks to me that this is an orphaned class; its implementation is
that of a simple getter and setter so it could not by itself be used to
generate sql without additional framework classes (which should then also be
in the framework to make this a usable feature).  It has not been touched in
years except in cross-cutting modifications like fixing whitespace or proper
generics syntax.

I would vote to remove.  It will still be in source control; so in a worst
case scenario any dependent upgrading implementation could request a quick
patch to pull it back in.
-- 
View this message in context: http://ofbiz.135035.n4.nabble.com/use-of-org-ofbiz-entity-condition-EntityClause-tp2233647p2234154.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: use of org.ofbiz.entity.condition.EntityClause

[Adam Heath <do...@brainfood.com>]

Adam Heath wrote:
> David E Jones wrote:
>> If this was removed, what would people who use this now use instead?
> 
> Nothing in ofbiz uses this class.  None of the sql generating code
> makes use of this class.  It literally is completely orphaned.
> 
> How is this class used to query the database?
> 
> Plus, look at EntityWhereString, which is close to EntityClause.

Replying to myself replying to David...

If this class really is used outside of ofbiz, then how is that done?
 Is there an example somewhere of how to do it?

> 
>> BTW, it is a general practice that we avoid any SQL (even parts of select clauses) in OFBiz itself since this introduces a risk of not working on certain databases. However, just because a feature isn't used in the OFBiz applications doesn't mean we should remove it from the OFBiz framework (if that was the case there is a LOT of stuff we should remove... the framework could be half its size!).
>>
>> -David
>>
>>
>> On May 27, 2010, at 1:18 PM, Adam Heath wrote:
>>
>>> I find no users of the above class anywhere in ofbiz.  I've searched
>>> the existing repository, and the previous one hosted on
>>> svn.ofbiz.org(still there).  I see no reason for that file to exist,
>>> and would like to remove it.
>>>
>>> I can guess what it might be used for, as a way to stitch random
>>> entities together in a generated sql string, that are not actually
>>> part of the parent query.  It's been relatively unchanged since Andrew
>>> did a test merge from a branch(doesn't say what) on Feb 22, 2005.
> 

Re: use of org.ofbiz.entity.condition.EntityClause

[Adam Heath <do...@brainfood.com>]

David E Jones wrote:
> If this was removed, what would people who use this now use instead?

Nothing in ofbiz uses this class.  None of the sql generating code
makes use of this class.  It literally is completely orphaned.

How is this class used to query the database?

Plus, look at EntityWhereString, which is close to EntityClause.

> 
> BTW, it is a general practice that we avoid any SQL (even parts of select clauses) in OFBiz itself since this introduces a risk of not working on certain databases. However, just because a feature isn't used in the OFBiz applications doesn't mean we should remove it from the OFBiz framework (if that was the case there is a LOT of stuff we should remove... the framework could be half its size!).
> 
> -David
> 
> 
> On May 27, 2010, at 1:18 PM, Adam Heath wrote:
> 
>> I find no users of the above class anywhere in ofbiz.  I've searched
>> the existing repository, and the previous one hosted on
>> svn.ofbiz.org(still there).  I see no reason for that file to exist,
>> and would like to remove it.
>>
>> I can guess what it might be used for, as a way to stitch random
>> entities together in a generated sql string, that are not actually
>> part of the parent query.  It's been relatively unchanged since Andrew
>> did a test merge from a branch(doesn't say what) on Feb 22, 2005.
> 

Re: use of org.ofbiz.entity.condition.EntityClause

[David E Jones <de...@me.com>]

If this was removed, what would people who use this now use instead?

BTW, it is a general practice that we avoid any SQL (even parts of select clauses) in OFBiz itself since this introduces a risk of not working on certain databases. However, just because a feature isn't used in the OFBiz applications doesn't mean we should remove it from the OFBiz framework (if that was the case there is a LOT of stuff we should remove... the framework could be half its size!).

-David


On May 27, 2010, at 1:18 PM, Adam Heath wrote:

> I find no users of the above class anywhere in ofbiz.  I've searched
> the existing repository, and the previous one hosted on
> svn.ofbiz.org(still there).  I see no reason for that file to exist,
> and would like to remove it.
> 
> I can guess what it might be used for, as a way to stitch random
> entities together in a generated sql string, that are not actually
> part of the parent query.  It's been relatively unchanged since Andrew
> did a test merge from a branch(doesn't say what) on Feb 22, 2005.