[Ovirt-devel] [PATCH server] Revised attempt at refactoring the vm_controller using the service layer.

[Scott Seago]

Ian Main wrote:
> On Tue, 21 Apr 2009 21:49:15 +0000
> David Lutterkort <lutter at redhat.com> wrote:
>
>   
>> On Tue, 2009-04-21 at 13:14 -0700, Ian Main wrote:
>>     
>>> So with this service layer.. with it being included and setting local
>>> properties of the object, will that be thread safe?  Or will we have
>>> to do locking around each call?
>>>
>>> I'm not sure yet if the agent will be threaded.. but it certainly
>>> could have a thread per method invocation..
>>>       
>> To echo what Scott said: I would prefer if we followed the rails model
>> fairly closely, with some sort of notion of a 'QMF controller', and
>> instantiate one for every method call from the QMF agent.
>>
>> Given that we want to minimize the amount of things we keep in memory
>> (mostly to avoid cache coherency issues between memory and DB), we want
>> the QMF API to be as statefree as possible.
>>     
>
> Yeah that makes sense.. the only place where it might be a little odd is
> in setting properties.  When properties are set it seems the way to do it
> is to load the vm properties hash from an active record and then call
> update() to have everything verified the same way as in rails?
>
> I'm not sure if there's any other way to verify the contents of various
> fields using the active record directly?  Either way it seems we need
> direct acccess to it as well.. is that a problem?
>
>     Ian
>
>   
Yes, to make persistent changes to VM properties here you would need to 
use the svc_update call. Or are you saying you also want to make changes 
to activerecord objects outside the service API layer? This would 
certainly be possible -- and if you call save! then any validation 
errors will raise exceptions just like they do in the svc method, 
although you'd lose the permission checks and any other business logic 
that is in the service layer.

Scott