Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Talk:EclipseLink/Development/AdditionalCriteria

Design details

The AdditionalCriteria maps to EclipseLink's existing descriptor additionalJoinExpression. The AdditionalCriteriaGroup and Callback and naming and enabled options are new functionality. Some insight into their requirement, usage, design and implementation in the runtime would be useful.

James.sutherland.oracle.com 19:11, 20 September 2010 (UTC)

Yes I will add details to that effect. This was merely the first stab at the metadata side of things. I will add more details concerning the core side of things next.

guy.pelletier.oracle.com 8:00, 21 September 2010 (UTC)

Callbacks

The callback seems quite complex, and uses reflection. Some similar to our DescriptorCustomizer and SessionCustomizer may be simpler. We could have a QueryCustomizer interface that takes a DatabaseQuery before execution and allows the user to customizes it. Or the existing SessionEventListener could be used.

James.sutherland.oracle.com 19:19, 20 September 2010 (UTC)

There is a requirement from Doug to provide this capability outside of a customizer, providing users with an easier configuration option.

guy.pelletier.oracle.com 8:00, 21 September 2010 (UTC)
A QueryCustomizer would still meet this requirement, and be consistent with our existing API, and not require reflection.
Another option would be a JPA event for preExecuteQuery that the user could annotate the same as any other JPA event, probably taking a JPA Query as argument, not a DatabaseQuery.
James.sutherland.oracle.com 13:13, 21 September 2010 (UTC)

JPQL

What is the context for the JPQL string, i.e. alias? Additional join expressions are normally table/field level. Will support be added to our JPQL support to allow referencing database fields/tables?

James.sutherland.oracle.com 19:24, 20 September 2010 (UTC)

I think that for the first phase the JPQL fragment has to be limited to a few simple rules. Any thing beyond should be left as an enhancement. My thoughts are that for phase one the following rules should be true:

two types of fragments will be supported:

1. leftSide comparator rightSide

 -where leftSide is a mapping, (eg firstname, or address.city)
 -comparator should be limited to these:
   =   // equal
   <>  // not equal
   !=  // not equal
   <   // less than
   <=  // less than or equal
   >   // greater than
   >=  // greater than or equal
   LIKE // like
  -rightSide is a litteral or a named argument (identified by starting with ':')

2. leftSide comparison

 -where leftSide is a mapping, (eg firstname, or address.city)
 -comparison is limited to:
  IS NULL
  IS NOT NULL
  IS EMPTY 
  IS NOT EMPTY
Peter.Krogh.oracle.com
Why limit anything? Aren't we just using our existing JPQL parser? I think it can parse a where clause only, and even if it can't maybe just prepend "Select this from <class> this where " to it and parse it and get the selectionCriteria from the resulting query, so the alias "this" would need to be used in the fragment ("this.isDeleted = false"), or better ("COLUMN(this, 'IS_DELETED') = false").
James.sutherland.oracle.com 13:13, 21 September 2010 (UTC)

Back to the top