On Nov 20, 2012, at 1:57 AM, David Lutterkort <[email protected]> wrote:

> On Tue, 2012-11-13 at 12:54 +0100, Michal Fojtik wrote:
>> The horrible looking 'uuid' field is SHA1 hash composed from 
>> credentials, driver name and provider string, so different clients will 
>> not override their properties.
> 
> We should not hash these things together - it makes understanding
> anything in the database much much harder. Instead, we need to have a
> provider table, akin to:
> 
>        class Provider
>            include DataMapper::Resource
> 
>            property :id,       Serial
>            property :driver,   String
>            property :provider, String
>            property :user,     String
> 
>            validates_uniqueness_of :user, :scope => [ :driver, :provider ]
>        end
> 
> and then reference that provider in the EntityProperty with
> belongs_to :provider.

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 :-)

> 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'.

> 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 :)

> 
>> http://tracker.deltacloud.org/set/123
> 
> This makes tracker very unhappy - but the patch you attached was good
> enough. I'll try and send a more detailed review later.

Sorry for that. I obsoleted that set, the new set ID is 130 :-)

  -- Michal

Michal Fojtik
http://deltacloud.org
[email protected]



Reply via email to