Re: [eclipselink-users] Virtual Metlhods | questions

[Gaurav Malhotra <gaurav.malhotra@xxxxxxxxxx>]

Hi Chris/Tom,
 I understand your's point, it will give it a try 

~Gaurav

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
> 
> 

-- 
View this message in context: http://old.nabble.com/Virtual-Metlhods-%7C-questions-tp34172077p34178209.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.