> -----Original Message-----
> From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
> Sent: Monday, September 03, 2012 4:12 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Info: How is Dao doing the update?
> 
> Hi,
> 
> Today I came one step close to understand the way GenericDao has
> implemented the update in DB.  I thought this understanding might be of use
> to someone who is new to CloudStack like myself. Please read on
> 
> Observation:
>                 Changes  in a setter in VO would never reflect in the DB.
> public setName(String name) {
> # it gets stored with the contents of argument "name" not "this.name"
>                 this.name  = "Name: " + name; }
> Reason:
>                 The setter functions of a VO are intercepted and 
> UpdateBuilder.java
> stores the argument in a private list "_changes" and this is what is used to
> update the DB at a later stage and *not* the object present in the member
> variable "this.name".
> 
> Suggestion/Fix:
>                 In my case I had a function like the following
>                 private String counterParameters; setCounterParameters(Map 
> map)
> {
>                 //loop through all the entry sets
>                 // concatenate them as a tempString  store it like the 
> following
> this.counterParameters = tempString; }
> 
> I changed it as
> 
> # Plain vanilla function that is intercepted for update
> setCounterParameters(String counterParmaaters) {
>                 this.counterParameters = counterParameters; } #custom setter
> which changes values setCounterParametersForUpdate(Map map) {
>                 // loop through all the entry sets
>                 // concatenate them as a tempString
> setCounterParameters(tempString); }
> 
> Any other Recommendation?:
>                 Is there a better way to get the Fix done?
> 

Vijay,

GenericDao was developed specifically to handle only entity mapping but not 
relational mapping.  The idea was that relational mapping is much easier to get 
wrong and best left to the programmer to specifically handle.  In your case, 
since there's a map, seems like you really want something to handle the 
relational mapping.  You shouldn't handle that in one DAO but write another DAO 
to take care of persisting it.

--Alex

Reply via email to