asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <dtab...@gmail.com>
Subject Re: Metadata changes
Date Mon, 14 Dec 2015 19:24:38 GMT
There is a way it could be done that'd be backwards compatible, I think.
Without careful thought, here's how that might look:
- One could make it officially optional (not predeclared, aka "closed).
- One could then make the semantics be that a type name's dataverse is 
either taken from there or presumed to be the same as dataset's 
dataverse if it's absent.
Would some fixed-up version of that work?
(It would clearly be cleaner long-term to NOT make it optional and to 
migrate existing metadata if we had any to have the new fully-qualified 
info based on the above semantics.  The question is - when do we cross 
that line where backward compatibility trumps - sorry to use that word 
:-) - cleanliness.  @All: Thoughts?)

On 12/14/15 11:16 AM, Steven Jacobs wrote:
> It's a new attribute, but it's a closed field, which means it isn't
> backwards compatible.
> Steven
>
> On Mon, Dec 14, 2015 at 11:13 AM, Ian Maxon <imaxon@uci.edu> wrote:
>
>> For 1), I guess the question is whether it would be a backwards
>> compatible change. Since it's just a new attribute (right?...), and it
>> is also sort of a new feature rather than a fix for something that was
>> critically broken, I would tend toward putting it on master. If it's
>> not backwards compatible though maybe it needs more careful
>> consideration.
>>
>> -Ian
>>
>> On Mon, Dec 14, 2015 at 10:12 AM, Steven Jacobs <sjaco002@ucr.edu> wrote:
>>> Hi all,
>>> I'm implementing a change so that datasets can use datatypes from
>> alternate
>>> data verses (previously the type and set had to be from the same
>>> dataverse). Unfortunately this means another change for Dataset Metadata
>>> (which will now store the dataverse for its type).
>>>
>>> As such, I had a couple of questions:
>>>
>>> 1) Should this change be thrown into the release branch, as it is another
>>> Metadata change?
>>>
>>> 2) In implementing this change, I've been looking at the Metadata
>> secondary
>>> indexes. I had a discussion with Ildar, and it seems the thread on
>> Metadata
>>> secondary indexes being "hacked" has been lost. Is this also something
>> that
>>> should get into the release? Is there anyone currently looking at it?
>>>
>>> Steven


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message