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 <[email protected]> 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 <[email protected]> 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
