Hi Wonseok,
Sorry for the delay.
For the cascade query hint, toplink.refresh.cascade or toplink.refresh-cascade have been proposed instead as the term policy doesn't add to hint's description.
The extensible query hint is a great idea, one we agree with. What has been suggested is that an enhancement request be created so that we can capture input on the issue, but so far we have the suggestion that this be done by making all hints available in events, callbacks, customizers, platforms etc - so that they can see the hints and do selective logic based on their values.
I'm not sure if this is different from what you envisioned this mechanism to be - possibly a hint listener/adapter type ie query events for JPA? If it is different (and this is why we need the enhancement request spelling it out a bit further) they can probably incorporated.
Best Regards,
Chris
From: Wonseok Kim
To: persistence_at_glassfish.dev.java.net
Sent: Wednesday, June 27, 2007 8:13 AM
Subject: Re: Code review for issue 1324: toplink.refresh query hint does not cascade
Hi Chris,
I've already implemented this feature. Please tell me what's going on the internal discussion about this, so I could show you the code snippet.
While I add a new query hint, I got an another idea on extensible query hint.
The basic idea is that we can make query hint implementation more extensible and easy to add to TopLink runtime by property, properties file or some other measure, then users can add their interested query hint like my cascade-policy hint by their own using underlying rich TopLink API.
This way is better than creating a Customizer class and modifying some named queries using TopLink API if user want customize some queries.
Also it opens a new contribution point and we can add contributed useful hint implementation to the main trunk(great!).
What do you think?
Cheers,
Wonseok
On 6/23/07, Christopher Delahunt <christopher.delahunt_at_oracle.com > wrote:
Hello Wonseok,
I think it's a great idea. I'm not sure what the CascadeAggregateDelete is, but I believe it might be good to also include a hint for CascadePrivateParts. While CascadePrivateParts isn't relevant with exclusive JPA relations, some users have requested privately owned functionality/features, which would be used with CascadePrivateParts. Users could mark relations as privately owned directly through TopLink apis, and so it would be nice for them to be able to use this hint on their queries when required.
As far as I know (but I'm working to verify it), CascadeAggregateDelete and the other cascade options apply to writeObjectQuery types such as Delete and UpdateObjectQuery instances too. Since these queries require setting the target object on the query (instead of parameters), there is no way for users to execute them using JPA, so the query hints will only apply to read/refresh type queries. I'll try and confirm this though with Gordon and get back to you on Monday. The query hint name will need to be approved, but I like the options.
Best Regards,
Chris
----- Original Message -----
From: Wonseok Kim
To: Christopher Delahunt ; persistence_at_glassfish.dev.java.net
Sent: Friday, June 22, 2007 10:37 AM
Subject: Re: Code review for issue 1324: toplink.refresh query hint does not cascade
Hi Chris,
I have an idea of new query hint to modify cascade policy. This enables application use dynamic refresh policy such as no-cascading or cascade-all in addition to default cascade-by-mapping. With this hint application can refresh related entities or do not cascade at all when required regardless of static "cascade=REFRESH" option. This could be done with TopLink customizer or TopLink API, but query hint would be more convenient.
When I look into DatabaseQuery several cascade policies are defined like below, but I'm not sure we should support all this policies. For refresh read query NoCascading, CascadeAllParts and CascadeByMapping seem to be meaningful.
-----
/* Used as default for read, means shallow write for modify. */
public static final int NoCascading = 1;
/* Used as default for write, used for refreshing to refresh the whole object. */
public static final int CascadePrivateParts = 2;
/* Currently not supported, used for deep write/refreshes/reads in the future. */
public static final int CascadeAllParts = 3;
/* Used by the unit of work. */
public static final int CascadeDependentParts = 4;
/* Used by aggregate Collections: As aggregates delete at update time, cascaded deletes
* must know to stop when entering postDelete for a particular mapping. Only used by the
* aggregate collection when update is occuring in a UnitOfWork
* CR 2811
*/
public static final int CascadeAggregateDelete = 5;
/*
* Used when refreshing should check the mappings to determin if a particular
* mapping should be cascaded.
*/
public static final int CascadeByMapping = 6;
-----
I'm curious this policy could be exploited for queries other than read query with refresh hint.
Depending on the usability of the cascade we could could either "toplink.cascade-policy " or "toplink.refresh.cascade-policy " as a hint name.
What do you think?
Regards,
Wonseok