<div dir="ltr">That is exactly option #2 which propose to store attributes in columns. So there will be a limited set of attributes and each of them will have its own column in a table.<div><br></div><div>Thanks</div><div>
Georgy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 10:55 AM, Paul Montgomery <span dir="ltr"><<a href="mailto:paul.montgomery@rackspace.com" target="_blank">paul.montgomery@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe a crazy idea butŠ<br>
<br>
What if we simply don't store the JSON blob data for M1 instead of putting<br>
storing it in a way we don't like long term?  This way, there is no need<br>
to remember to change something later even though a bug could be created<br>
anyways.  I believe the fields that would be missing/not stored in the<br>
blob are:<br>
<br>
* Compiler version<br>
* Language platform<br>
* OS platform<br>
<br>
Can we live with that for M1?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 2/18/14 12:07 PM, "Adrian Otto" <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>> wrote:<br>
<br>
>I agree. Let's proceed with option #2, and submit a wishlist bug to track<br>
>this as tech debt. We would like to come back to this later and add an<br>
>option to use a blob store for the JSON blob content, as Georgy<br>
>mentioned. These could be stored in swift, or a K/V store. It might be<br>
>nice to have a thin get/set abstraction there to allow alternates to be<br>
>implemented as needed.<br>
><br>
>I'm not sure exactly where we can track Paul Czarkowski's suggested<br>
>restriction. We may need to just rely on reviewers to prevent this,<br>
>because if we ever start introspecting the JSON blob, we will be using an<br>
>SQL anti-pattern. I'm generally opposed to putting arbitrary sized text<br>
>and blob entries into a SQL database, because eventually you may run into<br>
>the maximum allowable size (ie: max-allowed-packet) and cause unexpected<br>
>error conditions.<br>
><br>
>Thanks,<br>
><br>
>Adrian<br>
><br>
>On Feb 18, 2014, at 8:48 AM, Paul Czarkowski<br>
><<a href="mailto:paul.czarkowski@RACKSPACE.COM">paul.czarkowski@RACKSPACE.COM</a>><br>
> wrote:<br>
><br>
>> I'm also a +1 for #2.    However as discussed on IRC,  we should clearly<br>
>> spell out that the JSON blob should never be treated in a SQL-like<br>
>>manner.<br>
>>  The moment somebody says 'I want to make that item in the json<br>
>> searchable' is the time to discuss adding it as part of the SQL schema.<br>
>><br>
>> On 2/13/14 4:39 PM, "Clayton Coleman" <<a href="mailto:ccoleman@redhat.com">ccoleman@redhat.com</a>> wrote:<br>
>><br>
>>> I like option #2, simply because we should force ourselves to justify<br>
>>> every attribute that is extracted as a queryable parameter, rather than<br>
>>> making them queryable at the start.<br>
>>><br>
>>> ----- Original Message -----<br>
>>>> Hi Arati,<br>
>>>><br>
>>>><br>
>>>> I would vote for Option #2 as a short term solution. Probably later we<br>
>>>> can<br>
>>>> consider using NoSQL DB or MariaDB which has Column_JSON type to store<br>
>>>> complex types.<br>
>>>><br>
>>>> Thanks<br>
>>>> Georgy<br>
>>>><br>
>>>><br>
>>>> On Thu, Feb 13, 2014 at 8:12 AM, Arati Mahimane <<br>
>>>> <a href="mailto:arati.mahimane@rackspace.com">arati.mahimane@rackspace.com</a> > wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Hi All,<br>
>>>><br>
>>>> I have been working on defining the Language pack database schema.<br>
>>>>Here<br>
>>>> is a<br>
>>>> link to my review which is still a WIP -<br>
>>>> <a href="https://review.openstack.org/#/c/71132/3" target="_blank">https://review.openstack.org/#/c/71132/3</a> .<br>
>>>> There are a couple of different opinions on how we should be designing<br>
>>>> the<br>
>>>> schema.<br>
>>>><br>
>>>> Language pack has several complex attributes which are listed here -<br>
>>>> <a href="https://etherpad.openstack.org/p/Solum-Language-pack-json-format" target="_blank">https://etherpad.openstack.org/p/Solum-Language-pack-json-format</a><br>
>>>> We need to support search queries on language packs based on various<br>
>>>> criteria. One example could be 'find a language pack where type='java'<br>
>>>> and<br>
>>>> version>1.4'<br>
>>>><br>
>>>> Following are the two options that are currently being discussed for<br>
>>>> the DB<br>
>>>> schema:<br>
>>>><br>
>>>> Option 1: Having a separate table for each complex attribute, in order<br>
>>>> to<br>
>>>> achieve normalization. The current schema follows this approach.<br>
>>>> However, this design has certain drawbacks. It will result in a lot of<br>
>>>> complex DB queries and each new attribute will require a code change.<br>
>>>> Option 2: We could have a predefined subset of attributes on which we<br>
>>>> would<br>
>>>> support search queries.<br>
>>>> In this case, we would define columns (separate tables in case of<br>
>>>> complex<br>
>>>> attributes) only for this subset of attributes and all other<br>
>>>>attributes<br>
>>>> will<br>
>>>> be a part of a json blob.<br>
>>>> With this option, we will have to go through a schema change in case<br>
>>>>we<br>
>>>> decide to support search queries on other attributes at a later stage.<br>
>>>><br>
>>>> I would like to know everyone's thoughts on these two approaches so<br>
>>>> that we<br>
>>>> can take a final decision and go ahead with one approach.<br>
>>>> Suggestions regarding any other approaches are welcome too!<br>
>>>><br>
>>>> Thanks,<br>
>>>> Arati<br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Georgy Okrokvertskhov<br>
>>>> Architect,<br>
>>>> OpenStack Platform Products,<br>
>>>> Mirantis<br>
>>>> <a href="http://www.mirantis.com" target="_blank">http://www.mirantis.com</a><br>
>>>> Tel. <a href="tel:%2B1%20650%20963%209828" value="+16509639828">+1 650 963 9828</a><br>
>>>> Mob. <a href="tel:%2B1%20650%20996%203284" value="+16509963284">+1 650 996 3284</a><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><font color="#999999"><span style="background-color:rgb(255,255,255)">Georgy Okrokvertskhov<br>
Architect,<br><span style="font-family:arial;font-size:small">OpenStack Platform Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284</font><br></div>
</div>