asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <dtab...@gmail.com>
Subject Re: Dump and restore for AsterixDB datasets
Date Tue, 24 May 2016 22:56:56 GMT
Actually both.  We should test for binary back-compatibility but then 
have dump and restore (in serialized JSON) as a fallback so that when we 
break things, it's not hopeless for our users - they could dump 
(presumably a parallel process leaving JSON locally on each NC) and then 
restore (presumably a parallel process leading to "new binary" on each NC).


On 5/24/16 3:53 PM, Ildar Absalyamov wrote:
> I believe Mike meant binary roundtripability.
> How easy would it be to setup a Jenkins job which:
> 1) Takes a pre-commit version of Asterix, puts in tinySocial data, builds indexes, etc
> 2) Applies a commit and builds a new version.
> 3) Starts a new version with the old data and runs a tinySocial query set
> ?
>
>> On May 24, 2016, at 13:08, Ian Maxon <imaxon@uci.edu> wrote:
>>
>> The main problem right now is just the difference between the AQL that gets
>> output and the AQL the parser expects. We output the i64/i32 suffix for
>> example, but the parser doesn't like it (or at least that's how it was the
>> last time I tried this). I believe the are a few other rough edges like
>> this.
>>
>> On Tue, May 24, 2016 at 12:59 PM, Michael Carey <mjcarey@ics.uci.edu> wrote:
>>
>>> It's time for us to figure out how to get that working!!!  (Data
>>> roundtrips.)
>>>
>>> (So one could use that if we make unfortunate metadata/storage-format
>>> changes.)
>>>
>>> SDSC is getting serious about the data they are collecting (directly into
>>> AsterixDB, from social media, news, etc., sources.
>>>
>>>
>>>
> Best regards,
> Ildar
>


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