Open Stack

I like option #2, simply because we should force ourselves to justify every attribute that is extracted as a queryable parameter, rather than making them queryable at the start.

----- Original Message -----
> Hi Arati,
> 
> 
> I would vote for Option #2 as a short term solution. Probably later we can
> consider using NoSQL DB or MariaDB which has Column_JSON type to store
> complex types.
> 
> Thanks
> Georgy
> 
> 
> On Thu, Feb 13, 2014 at 8:12 AM, Arati Mahimane <
> arati.mahimane at rackspace.com > wrote:
> 
> 
> 
> Hi All,
> 
> I have been working on defining the Language pack database schema. Here is a
> link to my review which is still a WIP -
> https://review.openstack.org/#/c/71132/3 .
> There are a couple of different opinions on how we should be designing the
> schema.
> 
> Language pack has several complex attributes which are listed here -
> https://etherpad.openstack.org/p/Solum-Language-pack-json-format
> We need to support search queries on language packs based on various
> criteria. One example could be 'find a language pack where type='java' and
> version>1.4'
> 
> Following are the two options that are currently being discussed for the DB
> schema:
> 
> Option 1: Having a separate table for each complex attribute, in order to
> achieve normalization. The current schema follows this approach.
> However, this design has certain drawbacks. It will result in a lot of
> complex DB queries and each new attribute will require a code change.
> Option 2: We could have a predefined subset of attributes on which we would
> support search queries.
> In this case, we would define columns (separate tables in case of complex
> attributes) only for this subset of attributes and all other attributes will
> be a part of a json blob.
> With this option, we will have to go through a schema change in case we
> decide to support search queries on other attributes at a later stage.
> 
> I would like to know everyone's thoughts on these two approaches so that we
> can take a final decision and go ahead with one approach.
> Suggestions regarding any other approaches are welcome too!
> 
> Thanks,
> Arati
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> --
> Georgy Okrokvertskhov
> Architect,
> OpenStack Platform Products,
> Mirantis
> http://www.mirantis.com
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>