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
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
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
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.
Thanks
Georgy
On Tue, Feb 18, 2014 at 10:55 AM, Paul Montgomery
paul.montgom...@rackspace.com wrote:
Maybe a crazy idea
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.mahim...@rackspace.com wrote:
Hi All,
I have
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
