deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <lut...@redhat.com>
Subject Re: POC: DataMapper support for CIMI attributes
Date Wed, 21 Nov 2012 00:30:46 GMT
On Tue, 2012-11-20 at 14:59 +0100, Michal Fojtik wrote:
> This is exactly what I did after conversation with Dies last week, sorry for
> not updating this thread. The new patchset is uploaded here:
> 
> http://tracker.deltacloud.org/set/130
> 
> The updated set is using exactly the same model as you wrote above :-)

Must be correct then ;)

> > For my money, it would be enough to have one row for each entity, not
> > one for each property. I'd be happy with something like
> > 
> >        class Entity
> >          belongs_to :provider
> >          property :id, Serial
> >          property :be_type, String
> >          property :be_id, String
> >          property :properties, Json
> >          property :name, String
> >          property :description, String
> >        end
> > 
> > The idea is that we identify resources at the level of internal Instance
> > etc. classes, so that be_type would be 'instance' and be_id would be
> > 'inst42' ('be' is short for 'backend')
> 
> Sure, I currently the 'entity' property is used for this. The value
> stored there is something like 'instance:inst1'.

The reason I want to store stuff at the entity level is that it greatly
reduces the amount of rows in the DB, number of queries etc. Since we do
not need to do anything fancy with the data in the DB for now, there's
no need for the more granular data model of one row per property.

> > We should then be able to first look up the provider we are currently
> > working with, and then the proper entity given the backend model and its
> > id. We can then mix basic attributes like name and description in, as
> > well as the properties map (for now, storing that as JSON should be
> > fine) I am wondering if we shouldn't store base attributes as JSON, too.
> 
> Yes, this is an excellent point. I would love to make this work in way
> where we first try to use real provider and as a fallback we store attrs
> in database. But I'm afraid from using 'drivers' for this. I think we should
> keep this DB stuff out of Deltacloud drivers, we just need to figure out how to
> do it :)

We can do all this at the level of the CIMI frontend (collections):
_always_ store CIMI relevant data in the DB. When retrieving an entity,
prepopulate it with data from the DB, then overwrite with what we get
back from the driver - the overwriting would either happen with model
objects, or with the hashes we pass into the model object controllers.
That way, we always have CIMI relevant data, and use the 'real' backend
data when it is available.

David



Mime
View raw message