cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: Info: How is Dao doing the update?
Date Tue, 04 Sep 2012 17:25:12 GMT


> -----Original Message-----
> From: Vijay Venkatachalam [mailto:Vijay.Venkatachalam@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

Mime
View raw message