Open Stack

Maybe a crazy idea butŠ

What if we simply don't store the JSON blob data for M1 instead of putting
storing it in a way we don't like long term?  This way, there is no need
to remember to change something later even though a bug could be created
anyways.  I believe the fields that would be missing/not stored in the
blob are:

* Compiler version
* Language platform
* OS platform

Can we live with that for M1?


On 2/18/14 12:07 PM, "Adrian Otto" <adrian.otto at rackspace.com> wrote:

>I agree. Let's proceed with option #2, and submit a wishlist bug to track
>this as tech debt. We would like to come back to this later and add an
>option to use a blob store for the JSON blob content, as Georgy
>mentioned. These could be stored in swift, or a K/V store. It might be
>nice to have a thin get/set abstraction there to allow alternates to be
>implemented as needed.
>
>I'm not sure exactly where we can track Paul Czarkowski's suggested
>restriction. We may need to just rely on reviewers to prevent this,
>because if we ever start introspecting the JSON blob, we will be using an
>SQL anti-pattern. I'm generally opposed to putting arbitrary sized text
>and blob entries into a SQL database, because eventually you may run into
>the maximum allowable size (ie: max-allowed-packet) and cause unexpected
>error conditions.
>
>Thanks,
>
>Adrian
>
>On Feb 18, 2014, at 8:48 AM, Paul Czarkowski
><paul.czarkowski at RACKSPACE.COM>
> wrote:
>
>> 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
>> 
>> 
>> _______________________________________________
>> 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