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 CascadeAggregateDeleteis, 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 <guruwons_at_gmail.com>
> *To:* Christopher Delahunt <christopher.delahunt_at_oracle.com> ;
> 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
>
>