From: "Adam Heath" <doo...@brainfood.com>
On 05/24/2012 10:18 AM, Adam Heath wrote:
On 05/24/2012 08:15 AM, Adrian Crum wrote:
On 5/20/2012 10:01 AM, Jacques Le Roux wrote:
Quick questions (seems that there is a lack of internal
documentation to say the least), there are not only addressed to
Adam...
About javacc dependency do we really need it *OOTB*?
Can't we use rather externally maintained ant targets like in
ant-contrib? For instance pleaser read
http://markmail.org/message/lidw73cuzyfr6cic
What is framework\sql used for *OOTB*?
From what I understand, the sql component parses SQL statements into
OFBiz entity conditions, and then executes the statement using the
entity engine. I don't think it is used OOTB for anything, but it
could be useful for integration with third-party libraries that take
SQL statements - like Jasper Reports.
You can also parse *raw* where clauses.
==
import org.ofbiz.sql.Parser;
import org.ofbiz.entity.sql.EntityPlanner;
String sqlConditionString = "contactMechId = ?contactMechId";
def sqlPlanner = new EntityPlanner();
def reader = new StringReader(sqlCondition);
def sqlCondition = new Parser(reader).EntityCondition();
while (true) {
def condition = sqlPlanner.getConditionPlanner().parse(sqlCondition,
[contactMechId: '1']);
delegator.findList(entityName, condition, ....)
}
==
I suppose I should place some of that in a util class(SQLUtil comes to
mind, it was never finished).
I support (), and, or, in, between, it's rather complete.
The idea was that you would parse the sqlCondition once, in a static
{} block somewhere, then at runtime, just build that map. This
builds-upon the map/list idea inherent in ofbiz.
I also had plans that you could store sql strings into a properties
file somewhere, so that they could possibly be changed by the end-user
without having to recompile.
I need to revisit the "SELECT a.partyId, b.* EXCLUDE(partyId) FROM
Party a LEFT JOIN PartyContactMech b USING (partyId)", now that ofbiz
better supports conditions on the join clauses, esp. when combining
views into other views.
Thanks for the explanation,
So should we not rather create a Jira with all the needed in a patch until this
is finished?
Or maybe a branch would be easier?
Still with the slim-down idea in mind and as objective.
Jacques
