Open Stack

I'm also a +1 for #2.    However as discussed on IRC,  we should clearly
spell out that the JSON blob should never be treated in a SQL-like manner.
  The moment somebody says 'I want to make that item in the json
searchable' is the time to discuss adding it as part of the SQL schema.

On 2/13/14 4:39 PM, "Clayton Coleman" <ccoleman at redhat.com> wrote:

>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
>> 
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev