[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Virtual Metlhods | questions
|
Chris has got it exactly right here.
The only thing I'd like to add is that you'll only need ValueHolders for xToOne
Mappings. Transparent indirection works for xToMany. Depending on how you
choose to engineer your model, you may only need to use the get/set combination
that returns valueholders for xToOne mappings.
On 17/07/2012 1:32 PM, Christopher Delahunt wrote:
Hello Gaurav,
I think there is some confusion on what a ValueHolder instance is since your set
method seems to believe that a ValueHolderInterface can be an instance of
PhoneNumber. instead, A valueholder will contain the phonenumber - and the map
will contain a Valueholder instance that contains a PhoneNumber.
EclipseLink needs to set/get the valueholders within the map, but the
getters/setters you've provided are taking/returning PhoneNumber instances
instead. This is why you get the exception.
To get around this and still keep your app from seeing and having to deal
directly with valueholders you would create two sets of get/set methods. The
first set would be the ones EclipseLink would use to access what is in the map -
it will return exactly what is in there such as the valueholders etc. You can
call them something like getForEclipseLink/setForEclipseLink if you would like
to make it clear, and specify these method names in the VirtualAttributeAccessor.
You would then use the second set of get/set method to return the data the
application requires - such as the unwrapped data within the valueholders, much
as you seem to be doing in the get/set methods you posted earlier.
Regards,
Chris
On 17/07/2012 1:19 PM, Gaurav Malhotra wrote:
Hi tom,
It will be fine, if we uses some internal method for value holders. But
please give hint, how different attribute accessor will work as chris
suggested.
Gaurav
tware wrote:
Hi Gaurav,
Chris is right here. The way indirection works for 1-1 mappings in
EclipseLink, means that EclipseLink needs access to a method that will
return
the valueholder itself. With weaving enabled, we weave a special method
into
the object for each mapping.
The question here is whether the same method needs to be used to access
the
map from Groovy or if you could have an internal method EclipseLink uses
to
store the valueholders and a public method that is used to retrieve the
values?
-Tom
On 17/07/2012 10:43 AM, Gaurav Malhotra wrote:
Christopher,
I am trying to implement "Dynamic Fields" i.e. extension to
table/entity
which could be used in groovy logic as we call it dynamic logic.Dynamic
fields can be added dynamically at runtime (deployed cluster application
which also uses TLG). Currently in my sample code I use "EntryProcessor"
which is trigger the creation of mapping on all the nodes in the cluster.
Example, if we add dynamic field - "phoneNumber" to the Eomployee, it
should be possible to access it like employee.phoneNumber.number. Hence
Map
suit our use case (its simple) and we would not like to weave
getPhoneNumber method/attribute etc magically into the entity using asm.
Hence VirtualMethods implementation best suits our business usage
case.
So I think I cannot use any other attribute accessor.
~GM
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
