On Tue, May 15 2012, Loic Dachary wrote:
> On 05/15/2012 12:05 PM, Julien Danjou wrote:
>>
>> OTOH I find the metadata proposal in another table too much
>> complicated. Why not storing what metadata in the meter.payload field
>> in the same table (e.g. as a JSON string)?
> I would be much simpler to store the metadata in the resource_id field
> which could be renamed into resource field.
That'd be even more radical.
> Instead of resource_id=134123 we could have resource={ 'id': 134123,
> 'name': 'foobar', 'flavor': 'm1.small' etc.. } There would be no need
> for versioning, format, separate table, etc. etc. The only convention
> would be that it's a hash with at least one field : the id of the
> resource. The rest is metadata.
>
> It will use a lot of disk space with highly redundant information.
Ok, so the current proposal is just early optimization, as I understood.
If you want to optimize the storage, why not use resource_id as a
foreign key to the metatable table which would contains unique records
of metadata?
That would allow to store identical metadata once (and therefore
optimize space) and will be much simpler. There would not be any need of
version, timestamp, or whatever on metadata.
--
Julien Danjou
// eNovance http://enovance.com
// ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
