[jira] Created: (OFBIZ-4053) Implement an Entity Query Builder
Locked
[jira] Created: (OFBIZ-4053) Implement an Entity Query Builder
 
|
Implement an Entity Query Builder
--------------------------------- Key: OFBIZ-4053 URL: https://issues.apache.org/jira/browse/OFBIZ-4053 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: Scott Gray Assignee: Scott Gray As discussed on the dev list here: http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc Attached is an initial implementation of builder classes (of sorts) that make use of method chaining in order to simplify use of the Delegator interface to query entities. Rather than taking all possible query parameters into a single method as the delegator does, this implementation instead builds a query through a succession of distinct method calls. A simple example: {code} // Using the Delegator interface directly eli = delegator.find("FinAccountTrans", condition, null, null, UtilMisc.toList("-transactionDate"), null); // Using the new implementation eli = EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator(); {code} A more complex example: {code} // Delegator EntityCondition queryConditionsList = EntityCondition.makeCondition(allConditions, EntityOperator.AND); EntityFindOptions options = new EntityFindOptions(true, EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY, true); options.setMaxRows(viewSize * (viewIndex + 1)); EntityListIterator iterator = delegator.find("OrderHeader", queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options); // becomes EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct() .from("OrderHeader") .where(allConditions) .orderBy("orderDate DESC") .maxRows(viewSize * (viewIndex + 1)) .cursorScrollInsensitive() .iterator(); {code} A couple of issues with the implementation so far that I'm not entirely happy with: - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of something like EntityList.use(delegator). The latter requires less typing and I think is more intuitive than typing EntityBuilderUtil because of its similarities to the corresponding minilang method calls, I actually kept having trouble remembering what it was called when converting some delegator calls over. It also requires a little more typing (16-17 characters vs. 12-13), not a big deal but every little bit helps with what would be a very commonly used class. - I'm struggling to see the point of having the GenericQueryBuilder interface, the two classes share very little in the way of API and its use seems a little superfluous to me. Opinions on the above points or anything else to do with the implementation are most welcome. I'd like to get the API locked down (and hopefully some javadocs in place) before committing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Updated: (OFBIZ-4053) Implement an Entity Query Builder
|
|
[ https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray updated OFBIZ-4053: ------------------------------ Attachment: builder.patch > Implement an Entity Query Builder > --------------------------------- > > Key: OFBIZ-4053 > URL: https://issues.apache.org/jira/browse/OFBIZ-4053 > Project: OFBiz > Issue Type: New Feature > Components: framework > Affects Versions: SVN trunk > Reporter: Scott Gray > Assignee: Scott Gray > Attachments: builder.patch > > > As discussed on the dev list here: http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc > Attached is an initial implementation of builder classes (of sorts) that make use of method chaining in order to simplify use of the Delegator interface to query entities. > Rather than taking all possible query parameters into a single method as the delegator does, this implementation instead builds a query through a succession of distinct method calls. > A simple example: > {code} > // Using the Delegator interface directly > eli = delegator.find("FinAccountTrans", condition, null, null, UtilMisc.toList("-transactionDate"), null); > // Using the new implementation > eli = EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator(); > {code} > A more complex example: > {code} > // Delegator > EntityCondition queryConditionsList = EntityCondition.makeCondition(allConditions, EntityOperator.AND); > EntityFindOptions options = new EntityFindOptions(true, EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY, true); > options.setMaxRows(viewSize * (viewIndex + 1)); > EntityListIterator iterator = delegator.find("OrderHeader", queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options); > // becomes > EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct() > .from("OrderHeader") > .where(allConditions) > .orderBy("orderDate DESC") > .maxRows(viewSize * (viewIndex + 1)) > .cursorScrollInsensitive() > .iterator(); > {code} > A couple of issues with the implementation so far that I'm not entirely happy with: > - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of something like EntityList.use(delegator). The latter requires less typing and I think is more intuitive than typing EntityBuilderUtil because of its similarities to the corresponding minilang method calls, I actually kept having trouble remembering what it was called when converting some delegator calls over. It also requires a little more typing (16-17 characters vs. 12-13), not a big deal but every little bit helps with what would be a very commonly used class. > - I'm struggling to see the point of having the GenericQueryBuilder interface, the two classes share very little in the way of API and its use seems a little superfluous to me. > Opinions on the above points or anything else to do with the implementation are most welcome. I'd like to get the API locked down (and hopefully some javadocs in place) before committing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970214#action_12970214 ] Adam Heath commented on OFBIZ-4053: ----------------------------------- Maybe have a few static methods in Delegator, like this: Delegator.list(delegator).where().cache(). Also, why not add several where() variants, that mirror those in EntityCondition(and EntityFieldMap)? > Implement an Entity Query Builder > --------------------------------- > > Key: OFBIZ-4053 > URL: https://issues.apache.org/jira/browse/OFBIZ-4053 > Project: OFBiz > Issue Type: New Feature > Components: framework > Affects Versions: SVN trunk > Reporter: Scott Gray > Assignee: Scott Gray > Attachments: builder.patch > > > As discussed on the dev list here: http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc > Attached is an initial implementation of builder classes (of sorts) that make use of method chaining in order to simplify use of the Delegator interface to query entities. > Rather than taking all possible query parameters into a single method as the delegator does, this implementation instead builds a query through a succession of distinct method calls. > A simple example: > {code} > // Using the Delegator interface directly > eli = delegator.find("FinAccountTrans", condition, null, null, UtilMisc.toList("-transactionDate"), null); > // Using the new implementation > eli = EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator(); > {code} > A more complex example: > {code} > // Delegator > EntityCondition queryConditionsList = EntityCondition.makeCondition(allConditions, EntityOperator.AND); > EntityFindOptions options = new EntityFindOptions(true, EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY, true); > options.setMaxRows(viewSize * (viewIndex + 1)); > EntityListIterator iterator = delegator.find("OrderHeader", queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options); > // becomes > EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct() > .from("OrderHeader") > .where(allConditions) > .orderBy("orderDate DESC") > .maxRows(viewSize * (viewIndex + 1)) > .cursorScrollInsensitive() > .iterator(); > {code} > A couple of issues with the implementation so far that I'm not entirely happy with: > - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of something like EntityList.use(delegator). The latter requires less typing and I think is more intuitive than typing EntityBuilderUtil because of its similarities to the corresponding minilang method calls, I actually kept having trouble remembering what it was called when converting some delegator calls over. It also requires a little more typing (16-17 characters vs. 12-13), not a big deal but every little bit helps with what would be a very commonly used class. > - I'm struggling to see the point of having the GenericQueryBuilder interface, the two classes share very little in the way of API and its use seems a little superfluous to me. > Opinions on the above points or anything else to do with the implementation are most welcome. I'd like to get the API locked down (and hopefully some javadocs in place) before committing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970431#action_12970431 ] Scott Gray commented on OFBIZ-4053: ----------------------------------- Why static? How about instance methods: delegator.list().from("Person").query() delegator.one().from("Person).where("partyId", partyId).query() That's is my favorite so far and is amazingly easy to read. There are definitely still a ton of method variations worthy of being added, so far I've only added ones where I've come across a need for them while replacing delegator calls at random in the code base. > Implement an Entity Query Builder > --------------------------------- > > Key: OFBIZ-4053 > URL: https://issues.apache.org/jira/browse/OFBIZ-4053 > Project: OFBiz > Issue Type: New Feature > Components: framework > Affects Versions: SVN trunk > Reporter: Scott Gray > Assignee: Scott Gray > Attachments: builder.patch > > > As discussed on the dev list here: http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc > Attached is an initial implementation of builder classes (of sorts) that make use of method chaining in order to simplify use of the Delegator interface to query entities. > Rather than taking all possible query parameters into a single method as the delegator does, this implementation instead builds a query through a succession of distinct method calls. > A simple example: > {code} > // Using the Delegator interface directly > eli = delegator.find("FinAccountTrans", condition, null, null, UtilMisc.toList("-transactionDate"), null); > // Using the new implementation > eli = EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator(); > {code} > A more complex example: > {code} > // Delegator > EntityCondition queryConditionsList = EntityCondition.makeCondition(allConditions, EntityOperator.AND); > EntityFindOptions options = new EntityFindOptions(true, EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY, true); > options.setMaxRows(viewSize * (viewIndex + 1)); > EntityListIterator iterator = delegator.find("OrderHeader", queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options); > // becomes > EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct() > .from("OrderHeader") > .where(allConditions) > .orderBy("orderDate DESC") > .maxRows(viewSize * (viewIndex + 1)) > .cursorScrollInsensitive() > .iterator(); > {code} > A couple of issues with the implementation so far that I'm not entirely happy with: > - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of something like EntityList.use(delegator). The latter requires less typing and I think is more intuitive than typing EntityBuilderUtil because of its similarities to the corresponding minilang method calls, I actually kept having trouble remembering what it was called when converting some delegator calls over. It also requires a little more typing (16-17 characters vs. 12-13), not a big deal but every little bit helps with what would be a very commonly used class. > - I'm struggling to see the point of having the GenericQueryBuilder interface, the two classes share very little in the way of API and its use seems a little superfluous to me. > Opinions on the above points or anything else to do with the implementation are most welcome. I'd like to get the API locked down (and hopefully some javadocs in place) before committing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970485#action_12970485 ] Adam Heath commented on OFBIZ-4053: ----------------------------------- Because these methods are not unique to the delegator instance. Delegator is an interface, so you can't add abstract methods to that that are common to all implementations of Delegator.java. Plus, this api is more of a helper/util/worker type pattern, so should not be pushed into delegator directly. We've been slowly converting delegator to have just the bare minimum of methods on it. This set of methods is another way of fetching database values, which go against that. > Implement an Entity Query Builder > --------------------------------- > > Key: OFBIZ-4053 > URL: https://issues.apache.org/jira/browse/OFBIZ-4053 > Project: OFBiz > Issue Type: New Feature > Components: framework > Affects Versions: SVN trunk > Reporter: Scott Gray > Assignee: Scott Gray > Attachments: builder.patch > > > As discussed on the dev list here: http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc > Attached is an initial implementation of builder classes (of sorts) that make use of method chaining in order to simplify use of the Delegator interface to query entities. > Rather than taking all possible query parameters into a single method as the delegator does, this implementation instead builds a query through a succession of distinct method calls. > A simple example: > {code} > // Using the Delegator interface directly > eli = delegator.find("FinAccountTrans", condition, null, null, UtilMisc.toList("-transactionDate"), null); > // Using the new implementation > eli = EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator(); > {code} > A more complex example: > {code} > // Delegator > EntityCondition queryConditionsList = EntityCondition.makeCondition(allConditions, EntityOperator.AND); > EntityFindOptions options = new EntityFindOptions(true, EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY, true); > options.setMaxRows(viewSize * (viewIndex + 1)); > EntityListIterator iterator = delegator.find("OrderHeader", queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options); > // becomes > EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct() > .from("OrderHeader") > .where(allConditions) > .orderBy("orderDate DESC") > .maxRows(viewSize * (viewIndex + 1)) > .cursorScrollInsensitive() > .iterator(); > {code} > A couple of issues with the implementation so far that I'm not entirely happy with: > - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of something like EntityList.use(delegator). The latter requires less typing and I think is more intuitive than typing EntityBuilderUtil because of its similarities to the corresponding minilang method calls, I actually kept having trouble remembering what it was called when converting some delegator calls over. It also requires a little more typing (16-17 characters vs. 12-13), not a big deal but every little bit helps with what would be a very commonly used class. > - I'm struggling to see the point of having the GenericQueryBuilder interface, the two classes share very little in the way of API and its use seems a little superfluous to me. > Opinions on the above points or anything else to do with the implementation are most welcome. I'd like to get the API locked down (and hopefully some javadocs in place) before committing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970493#action_12970493 ] Adam Heath commented on OFBIZ-4053: ----------------------------------- I'd be nice to have a helper method, that when called, would return a string that shows which full method on the delegator would be called with the current set of parameters. This is complicated, as this string would have to deserialize any maps or conditions. > Implement an Entity Query Builder > --------------------------------- > > Key: OFBIZ-4053 > URL: https://issues.apache.org/jira/browse/OFBIZ-4053 > Project: OFBiz > Issue Type: New Feature > Components: framework > Affects Versions: SVN trunk > Reporter: Scott Gray > Assignee: Scott Gray > Attachments: builder.patch > > > As discussed on the dev list here: http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc > Attached is an initial implementation of builder classes (of sorts) that make use of method chaining in order to simplify use of the Delegator interface to query entities. > Rather than taking all possible query parameters into a single method as the delegator does, this implementation instead builds a query through a succession of distinct method calls. > A simple example: > {code} > // Using the Delegator interface directly > eli = delegator.find("FinAccountTrans", condition, null, null, UtilMisc.toList("-transactionDate"), null); > // Using the new implementation > eli = EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator(); > {code} > A more complex example: > {code} > // Delegator > EntityCondition queryConditionsList = EntityCondition.makeCondition(allConditions, EntityOperator.AND); > EntityFindOptions options = new EntityFindOptions(true, EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY, true); > options.setMaxRows(viewSize * (viewIndex + 1)); > EntityListIterator iterator = delegator.find("OrderHeader", queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options); > // becomes > EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct() > .from("OrderHeader") > .where(allConditions) > .orderBy("orderDate DESC") > .maxRows(viewSize * (viewIndex + 1)) > .cursorScrollInsensitive() > .iterator(); > {code} > A couple of issues with the implementation so far that I'm not entirely happy with: > - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of something like EntityList.use(delegator). The latter requires less typing and I think is more intuitive than typing EntityBuilderUtil because of its similarities to the corresponding minilang method calls, I actually kept having trouble remembering what it was called when converting some delegator calls over. It also requires a little more typing (16-17 characters vs. 12-13), not a big deal but every little bit helps with what would be a very commonly used class. > - I'm struggling to see the point of having the GenericQueryBuilder interface, the two classes share very little in the way of API and its use seems a little superfluous to me. > Opinions on the above points or anything else to do with the implementation are most welcome. I'd like to get the API locked down (and hopefully some javadocs in place) before committing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970510#action_12970510 ] Scott Gray commented on OFBIZ-4053: ----------------------------------- I'm just trying to create an easy to use API, if the answer is "you can't do that because it goes against best practices" well then I don't know what do to. All of your alternatives so far have resulted in more typing to get access to the EntityList/One objects which is exactly what I'm trying to avoid. If these object gained widespread usage (which is my intention) then all of the delegator's convenience select methods could be deprecated. > Implement an Entity Query Builder > --------------------------------- > > Key: OFBIZ-4053 > URL: https://issues.apache.org/jira/browse/OFBIZ-4053 > Project: OFBiz > Issue Type: New Feature > Components: framework > Affects Versions: SVN trunk > Reporter: Scott Gray > Assignee: Scott Gray > Attachments: builder.patch > > > As discussed on the dev list here: http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc > Attached is an initial implementation of builder classes (of sorts) that make use of method chaining in order to simplify use of the Delegator interface to query entities. > Rather than taking all possible query parameters into a single method as the delegator does, this implementation instead builds a query through a succession of distinct method calls. > A simple example: > {code} > // Using the Delegator interface directly > eli = delegator.find("FinAccountTrans", condition, null, null, UtilMisc.toList("-transactionDate"), null); > // Using the new implementation > eli = EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator(); > {code} > A more complex example: > {code} > // Delegator > EntityCondition queryConditionsList = EntityCondition.makeCondition(allConditions, EntityOperator.AND); > EntityFindOptions options = new EntityFindOptions(true, EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY, true); > options.setMaxRows(viewSize * (viewIndex + 1)); > EntityListIterator iterator = delegator.find("OrderHeader", queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options); > // becomes > EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct() > .from("OrderHeader") > .where(allConditions) > .orderBy("orderDate DESC") > .maxRows(viewSize * (viewIndex + 1)) > .cursorScrollInsensitive() > .iterator(); > {code} > A couple of issues with the implementation so far that I'm not entirely happy with: > - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of something like EntityList.use(delegator). The latter requires less typing and I think is more intuitive than typing EntityBuilderUtil because of its similarities to the corresponding minilang method calls, I actually kept having trouble remembering what it was called when converting some delegator calls over. It also requires a little more typing (16-17 characters vs. 12-13), not a big deal but every little bit helps with what would be a very commonly used class. > - I'm struggling to see the point of having the GenericQueryBuilder interface, the two classes share very little in the way of API and its use seems a little superfluous to me. > Opinions on the above points or anything else to do with the implementation are most welcome. I'd like to get the API locked down (and hopefully some javadocs in place) before committing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970519#action_12970519 ] BJ Freeman commented on OFBIZ-4053: ----------------------------------- if I under stand you want to replace current coding with a Class the generates. Based on Davids past comments using Classes add extra conversion. though I like your Ideas I suggest if be web tool that generates the standard code from the input, that could be pasted into say simple methods. > Implement an Entity Query Builder > --------------------------------- > > Key: OFBIZ-4053 > URL: https://issues.apache.org/jira/browse/OFBIZ-4053 > Project: OFBiz > Issue Type: New Feature > Components: framework > Affects Versions: SVN trunk > Reporter: Scott Gray > Assignee: Scott Gray > Attachments: builder.patch > > > As discussed on the dev list here: http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc > Attached is an initial implementation of builder classes (of sorts) that make use of method chaining in order to simplify use of the Delegator interface to query entities. > Rather than taking all possible query parameters into a single method as the delegator does, this implementation instead builds a query through a succession of distinct method calls. > A simple example: > {code} > // Using the Delegator interface directly > eli = delegator.find("FinAccountTrans", condition, null, null, UtilMisc.toList("-transactionDate"), null); > // Using the new implementation > eli = EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator(); > {code} > A more complex example: > {code} > // Delegator > EntityCondition queryConditionsList = EntityCondition.makeCondition(allConditions, EntityOperator.AND); > EntityFindOptions options = new EntityFindOptions(true, EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY, true); > options.setMaxRows(viewSize * (viewIndex + 1)); > EntityListIterator iterator = delegator.find("OrderHeader", queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options); > // becomes > EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct() > .from("OrderHeader") > .where(allConditions) > .orderBy("orderDate DESC") > .maxRows(viewSize * (viewIndex + 1)) > .cursorScrollInsensitive() > .iterator(); > {code} > A couple of issues with the implementation so far that I'm not entirely happy with: > - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of something like EntityList.use(delegator). The latter requires less typing and I think is more intuitive than typing EntityBuilderUtil because of its similarities to the corresponding minilang method calls, I actually kept having trouble remembering what it was called when converting some delegator calls over. It also requires a little more typing (16-17 characters vs. 12-13), not a big deal but every little bit helps with what would be a very commonly used class. > - I'm struggling to see the point of having the GenericQueryBuilder interface, the two classes share very little in the way of API and its use seems a little superfluous to me. > Opinions on the above points or anything else to do with the implementation are most welcome. I'd like to get the API locked down (and hopefully some javadocs in place) before committing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970523#action_12970523 ] Scott Gray commented on OFBIZ-4053: ----------------------------------- Hi BJ, I don't think you do understand, perhaps looking at the patch might better explain the concept. > Implement an Entity Query Builder > --------------------------------- > > Key: OFBIZ-4053 > URL: https://issues.apache.org/jira/browse/OFBIZ-4053 > Project: OFBiz > Issue Type: New Feature > Components: framework > Affects Versions: SVN trunk > Reporter: Scott Gray > Assignee: Scott Gray > Attachments: builder.patch > > > As discussed on the dev list here: http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc > Attached is an initial implementation of builder classes (of sorts) that make use of method chaining in order to simplify use of the Delegator interface to query entities. > Rather than taking all possible query parameters into a single method as the delegator does, this implementation instead builds a query through a succession of distinct method calls. > A simple example: > {code} > // Using the Delegator interface directly > eli = delegator.find("FinAccountTrans", condition, null, null, UtilMisc.toList("-transactionDate"), null); > // Using the new implementation > eli = EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator(); > {code} > A more complex example: > {code} > // Delegator > EntityCondition queryConditionsList = EntityCondition.makeCondition(allConditions, EntityOperator.AND); > EntityFindOptions options = new EntityFindOptions(true, EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY, true); > options.setMaxRows(viewSize * (viewIndex + 1)); > EntityListIterator iterator = delegator.find("OrderHeader", queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options); > // becomes > EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct() > .from("OrderHeader") > .where(allConditions) > .orderBy("orderDate DESC") > .maxRows(viewSize * (viewIndex + 1)) > .cursorScrollInsensitive() > .iterator(); > {code} > A couple of issues with the implementation so far that I'm not entirely happy with: > - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of something like EntityList.use(delegator). The latter requires less typing and I think is more intuitive than typing EntityBuilderUtil because of its similarities to the corresponding minilang method calls, I actually kept having trouble remembering what it was called when converting some delegator calls over. It also requires a little more typing (16-17 characters vs. 12-13), not a big deal but every little bit helps with what would be a very commonly used class. > - I'm struggling to see the point of having the GenericQueryBuilder interface, the two classes share very little in the way of API and its use seems a little superfluous to me. > Opinions on the above points or anything else to do with the implementation are most welcome. I'd like to get the API locked down (and hopefully some javadocs in place) before committing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970884#action_12970884 ] Adrian Crum commented on OFBIZ-4053: ------------------------------------ I like the concept, and I agree that this new functionality should be implemented without adding a bunch of new methods to the Delegator interface. It might help to get everyone to agree on the syntax before discussing the implementation details. My preference would be something like: {code} Query query = Query.newInstance(delegator); // "create" would be better, but it might cause method name clash EntityListIterator iterator = query.distinct() .from("OrderHeader") .where(allConditions) .orderBy("orderDate DESC") .maxRows(viewSize * (viewIndex + 1)) .cursorScrollInsensitive() .iterator(); {code} > Implement an Entity Query Builder > --------------------------------- > > Key: OFBIZ-4053 > URL: https://issues.apache.org/jira/browse/OFBIZ-4053 > Project: OFBiz > Issue Type: New Feature > Components: framework > Affects Versions: SVN trunk > Reporter: Scott Gray > Assignee: Scott Gray > Attachments: builder.patch > > > As discussed on the dev list here: http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc > Attached is an initial implementation of builder classes (of sorts) that make use of method chaining in order to simplify use of the Delegator interface to query entities. > Rather than taking all possible query parameters into a single method as the delegator does, this implementation instead builds a query through a succession of distinct method calls. > A simple example: > {code} > // Using the Delegator interface directly > eli = delegator.find("FinAccountTrans", condition, null, null, UtilMisc.toList("-transactionDate"), null); > // Using the new implementation > eli = EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator(); > {code} > A more complex example: > {code} > // Delegator > EntityCondition queryConditionsList = EntityCondition.makeCondition(allConditions, EntityOperator.AND); > EntityFindOptions options = new EntityFindOptions(true, EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY, true); > options.setMaxRows(viewSize * (viewIndex + 1)); > EntityListIterator iterator = delegator.find("OrderHeader", queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options); > // becomes > EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct() > .from("OrderHeader") > .where(allConditions) > .orderBy("orderDate DESC") > .maxRows(viewSize * (viewIndex + 1)) > .cursorScrollInsensitive() > .iterator(); > {code} > A couple of issues with the implementation so far that I'm not entirely happy with: > - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of something like EntityList.use(delegator). The latter requires less typing and I think is more intuitive than typing EntityBuilderUtil because of its similarities to the corresponding minilang method calls, I actually kept having trouble remembering what it was called when converting some delegator calls over. It also requires a little more typing (16-17 characters vs. 12-13), not a big deal but every little bit helps with what would be a very commonly used class. > - I'm struggling to see the point of having the GenericQueryBuilder interface, the two classes share very little in the way of API and its use seems a little superfluous to me. > Opinions on the above points or anything else to do with the implementation are most welcome. I'd like to get the API locked down (and hopefully some javadocs in place) before committing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Issue Comment Edited: (OFBIZ-4053) Implement an Entity Query Builder
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970884#action_12970884 ] Adrian Crum edited comment on OFBIZ-4053 at 12/13/10 11:42 AM: --------------------------------------------------------------- I like the concept, and I agree that this new functionality should be implemented without adding a bunch of new methods to the Delegator interface. It might help to get everyone to agree on the syntax before discussing the implementation details. My preference would be something like: {code} Query query = Query.newInstance(delegator); // "create" would be better, but it might cause method name clash EntityListIterator iterator = query.distinct() .from("OrderHeader") .where(allConditions) .orderBy("orderDate DESC") .maxRows(viewSize * (viewIndex + 1)) .cursorScrollInsensitive() .iterator(); {code} was (Author: [hidden email]): I like the concept, and I agree that this new functionality should be implemented without adding a bunch of new methods to the Delegator interface. It might help to get everyone to agree on the syntax before discussing the implementation details. My preference would be something like: {code} Query query = Query.newInstance(delegator); // "create" would be better, but it might cause method name clash EntityListIterator iterator = query.distinct() .from("OrderHeader") .where(allConditions) .orderBy("orderDate DESC") .maxRows(viewSize * (viewIndex + 1)) .cursorScrollInsensitive() .iterator(); {code} > Implement an Entity Query Builder > --------------------------------- > > Key: OFBIZ-4053 > URL: https://issues.apache.org/jira/browse/OFBIZ-4053 > Project: OFBiz > Issue Type: New Feature > Components: framework > Affects Versions: SVN trunk > Reporter: Scott Gray > Assignee: Scott Gray > Attachments: builder.patch > > > As discussed on the dev list here: http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc > Attached is an initial implementation of builder classes (of sorts) that make use of method chaining in order to simplify use of the Delegator interface to query entities. > Rather than taking all possible query parameters into a single method as the delegator does, this implementation instead builds a query through a succession of distinct method calls. > A simple example: > {code} > // Using the Delegator interface directly > eli = delegator.find("FinAccountTrans", condition, null, null, UtilMisc.toList("-transactionDate"), null); > // Using the new implementation > eli = EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator(); > {code} > A more complex example: > {code} > // Delegator > EntityCondition queryConditionsList = EntityCondition.makeCondition(allConditions, EntityOperator.AND); > EntityFindOptions options = new EntityFindOptions(true, EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY, true); > options.setMaxRows(viewSize * (viewIndex + 1)); > EntityListIterator iterator = delegator.find("OrderHeader", queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options); > // becomes > EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct() > .from("OrderHeader") > .where(allConditions) > .orderBy("orderDate DESC") > .maxRows(viewSize * (viewIndex + 1)) > .cursorScrollInsensitive() > .iterator(); > {code} > A couple of issues with the implementation so far that I'm not entirely happy with: > - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of something like EntityList.use(delegator). The latter requires less typing and I think is more intuitive than typing EntityBuilderUtil because of its similarities to the corresponding minilang method calls, I actually kept having trouble remembering what it was called when converting some delegator calls over. It also requires a little more typing (16-17 characters vs. 12-13), not a big deal but every little bit helps with what would be a very commonly used class. > - I'm struggling to see the point of having the GenericQueryBuilder interface, the two classes share very little in the way of API and its use seems a little superfluous to me. > Opinions on the above points or anything else to do with the implementation are most welcome. I'd like to get the API locked down (and hopefully some javadocs in place) before committing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Issue Comment Edited: (OFBIZ-4053) Implement an Entity Query Builder
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970884#action_12970884 ] Adrian Crum edited comment on OFBIZ-4053 at 12/13/10 11:45 AM: --------------------------------------------------------------- I like the concept, and I agree that this new functionality should be implemented without adding a bunch of new methods to the Delegator interface. It might help to get everyone to agree on the syntax before discussing the implementation details. My preference would be something like: {code} Query query = Query.newInstance(delegator); // "create" would be better, but it might cause method name clash EntityListIterator iterator = query.execute() .distinct() .from("OrderHeader") .where(allConditions) .orderBy("orderDate DESC") .maxRows(viewSize * (viewIndex + 1)) .cursorScrollInsensitive() .iterator(); {code} was (Author: [hidden email]): I like the concept, and I agree that this new functionality should be implemented without adding a bunch of new methods to the Delegator interface. It might help to get everyone to agree on the syntax before discussing the implementation details. My preference would be something like: {code} Query query = Query.newInstance(delegator); // "create" would be better, but it might cause method name clash EntityListIterator iterator = query.distinct() .from("OrderHeader") .where(allConditions) .orderBy("orderDate DESC") .maxRows(viewSize * (viewIndex + 1)) .cursorScrollInsensitive() .iterator(); {code} > Implement an Entity Query Builder > --------------------------------- > > Key: OFBIZ-4053 > URL: https://issues.apache.org/jira/browse/OFBIZ-4053 > Project: OFBiz > Issue Type: New Feature > Components: framework > Affects Versions: SVN trunk > Reporter: Scott Gray > Assignee: Scott Gray > Attachments: builder.patch > > > As discussed on the dev list here: http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc > Attached is an initial implementation of builder classes (of sorts) that make use of method chaining in order to simplify use of the Delegator interface to query entities. > Rather than taking all possible query parameters into a single method as the delegator does, this implementation instead builds a query through a succession of distinct method calls. > A simple example: > {code} > // Using the Delegator interface directly > eli = delegator.find("FinAccountTrans", condition, null, null, UtilMisc.toList("-transactionDate"), null); > // Using the new implementation > eli = EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator(); > {code} > A more complex example: > {code} > // Delegator > EntityCondition queryConditionsList = EntityCondition.makeCondition(allConditions, EntityOperator.AND); > EntityFindOptions options = new EntityFindOptions(true, EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY, true); > options.setMaxRows(viewSize * (viewIndex + 1)); > EntityListIterator iterator = delegator.find("OrderHeader", queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options); > // becomes > EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct() > .from("OrderHeader") > .where(allConditions) > .orderBy("orderDate DESC") > .maxRows(viewSize * (viewIndex + 1)) > .cursorScrollInsensitive() > .iterator(); > {code} > A couple of issues with the implementation so far that I'm not entirely happy with: > - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of something like EntityList.use(delegator). The latter requires less typing and I think is more intuitive than typing EntityBuilderUtil because of its similarities to the corresponding minilang method calls, I actually kept having trouble remembering what it was called when converting some delegator calls over. It also requires a little more typing (16-17 characters vs. 12-13), not a big deal but every little bit helps with what would be a very commonly used class. > - I'm struggling to see the point of having the GenericQueryBuilder interface, the two classes share very little in the way of API and its use seems a little superfluous to me. > Opinions on the above points or anything else to do with the implementation are most welcome. I'd like to get the API locked down (and hopefully some javadocs in place) before committing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |