Hi Chris,
I filed an enhancement issue for this.
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3269
And please review the attached implementation code for this. I choosed "
toplink.refresh.cascade" for the hint name.
With the implementation I also added test codes to confirm whether the hint
is applied.
This is tested with entity-persistence-tests and my local refresh testcase.
Regarding the extensible query hint, I will come up with more concrete idea
and code later.
Thanks,
Wonseok
On 6/29/07, Christopher Delahunt <christopher.delahunt_at_oracle.com> wrote:
>
> 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 <guruwons_at_gmail.com>
> *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 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
> >
> >
>