From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
From: "Adam Heath" <doo...@brainfood.com>
On 05/24/2012 04:05 PM, Jacques Le Roux wrote:
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.
I like the slimdown, but tbh, I would like to see the framework/sql stuff used more than it is(0 right now). Andrew Zeneski was
an original requestor for something that parsed sql into EntityCondition. I took his suggestion, but went further, to allow
CREATE VIEW AS SELECT to work.
I've noticed that there aren't that many view definitions in ofbiz. As I've been deprecating all this code recently, I've
noticed java code doing nested loop kinda-stuff, instead of just doing a view. I'm guessing because view-xml is verbose and not
how people actually think.
However, with what I committed, you can define the view using a SQL syntax,
which is then backed by a DynamicViewEntity.
I've seen rather impressive speedups just rewriting code to a single SQL query, instead of java loops; the database can be rather
efficient. So making view writing simpler is a laudable goal.
Great, but still, why not a branch as long as it's not finished?
Also something which I think is pretty neat in the principle (I still did not review the code) and would speed up views:
https://issues.apache.org/jira/browse/OFBIZ-4041
Jacques
BTW another stuff that could be part of this branch
https://issues.apache.org/jira/browse/OFBIZ-3575
Jacques
