Thanks Prachi. I was looking at CLOUDSTACK-5458 when I came across this. I don't quite follow the logic of multiple VOs based on a subset of fields. If multiple VOs are targeting a subset of fields for the same row in the db. then that essentially means that the fields in each subset must be independent of each other. If there is any dependency between the subsets/views than managing them will be very complex. One service can update its subset of fields and make the other fields inconsistent (the specific bug I have mentioned is an example). And if the subsets must be independent then isn't it simpler to have separate tables?
Also why the VMEntityVO has fields like cpu, speed, memory when these are already part of service offering? -Koushik On 17-Dec-2013, at 3:18 AM, Prachi Damle <prachi.da...@citrix.com> wrote: > Koushik, > > This is part of the cloud-engine / orchestration layer refactoring started in > 4.1. The final idea is to separate out the cloudstack API layer and the > orchestration logic into different services. Each service will have its own > set of VO's as per the view the service works with. Thus the VO will > populate/retrieve only those fields that are visible/essential for that > service functionality. Hence you see some difference in the two VO's you > mention. > The VM deployment API layer works with VMInstanceVO ; while the orchestration > flow works with VMEntityVO. > > There are many other entities for which this has been done so far, Alex has > put everything under cloud-engine-schema recently where you can find some > more of such examples. > > Prachi > > -----Original Message----- > From: Koushik Das > Sent: Sunday, December 15, 2013 9:50 PM > To: <dev@cloudstack.apache.org> > Cc: Prachi Damle > Subject: Re: VMEntityVO and VMInstanceVO > > Prachi, From the history I see that you added VMEntityVO. Any specific reason > for having both? > > On 12-Dec-2013, at 2:36 PM, Koushik Das <koushik....@citrix.com> wrote: > >> I see that both the VOs uses the same vm_instance table. What is the need >> for having 2 VOs for the same table? Should one be removed? >> Also VMEntityVO I see a field called "speed" which is not there in >> VMInstanceVO. Why this discrepancy? >> >> Thanks, >> Koushik >
