On Tue, May 15, 2012 at 10:26 AM, Doug Hellmann <doug...@dreamhost.com <mailto:doug...@dreamhost.com>> wrote:

On Tue, May 15, 2012 at 8:21 AM, Julien Danjou <juli...@enovance.com <mailto:juli...@enovance.com>> wrote:

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.

I like it because it would simplify the messaging. We can leave the storage optimization question to the daemon that stores the data.

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