May be doing a little example code that shows how it works and the performance impact can help developers with implementation in various areas.
Regards, Pierre 2012/5/25 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<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. >
