Bugzilla – Full Text Bug Listing
| Summary: | QueryByExamplePolicy addSpecialOperation with attribute names | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Jeff Domeyer <domeyerj> | ||||||
| Component: | Eclipselink | Assignee: | Nobody - feel free to take it <nobody> | ||||||
| Status: | NEW --- | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | tom.ware | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | submitted_patch | ||||||||
| Attachments: |
|
||||||||
Created attachment 195851 [details]
proposed-patch
Is this working for you? Can you provide a sample of how you are using it? Created attachment 203110 [details]
Sample maven project utilizing the patch
Sorry it took so long to get back to this!
The sample project just shows that it works, but it's not a clear use-case scenario. The enhancement allows for a more targeted application of special operations. Before you'd specify that Date classes should match the equal operation, whereas my use-case needs 2 different operations depending on if it's a startDate or an endDate. The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |
Currently when you are working with a QBEPolicy, you can only add special operations for class types. So if an attribute is of type String.class, then you can apply a special operation. I've taken a stab at adding special operations with respect to attribute names with regular expression matching. That way you can identify all attributes that end with "Date" ("Date$") and apply a special operation. If this seems like a good idea, I'd like to continue with adding more capabilities into the QBEPolicy. My current need is to apply logic of the nature: startDate !>= some date and endDate !<= same date In order to acquire effectively dated records that overlap with the specified start and end date. Adding the "not" into the mix is where it gets sticky as the only operation currently supported with "not" is notEqual. So if I get a nod, I'll continue with this enhancement.