Question: Shouldn't eventData.changedRows[0] return the new state of any changed rows via the changed history point when undo/redo is triggered?

I have an on("change") function set up that listens for changes to a table. I have an undoing and a redoing variable, the values of which are tied to undo and redo buttons.

Note the 2 console.log's in my on("change") function. You can see that eventData.changedRows[0] always returns the latest point in history rather than the current history point after undo/redo.

I'm getting around that right now by running a query to retrieve the changed row which does return the current history point so I'm able to get it to work. Just wondered if that was your intention for this.

Below is a screenshot of the console.log's highlighted.

(NOTE: Just as a FYI, .settings.activeSelectors.options[0] is the field I'm changing in order to test to keep my log's a little more simplified. In the first history point I assigned "testing one" as the value and in the next assigned "testing one two" )

nSQL("aniblocks").on('change',function(eventData) {

  getHistory();

  switch(eventData.changeType) {
    case 'modified':
      if(eventData.changedRows.length > 0) {

        // eventData.changedRows[0] contains data from the latest history point
        console.log('row: ',eventData.changedRows[0].settings.activeSelectors.options[0]);

        if( undoing || redoing ) {
          db.query('select').where(['id','=', eventData.changedRows[0].id]).exec()
          .then(function(result,db){

            // result contains data from the current history point after an undo/redo
            console.log(result[0].settings.activeSelectors.options[0]);
           
            // doing stuff with it here
            animationsMgr.animateFromDB(result[0]);
            resetDoingVars();
          })
        }
      } else {
        // console.log('nothing changed');
      }
    break;
    case 'deleted':
      console.log('deleted');
    break;
    case 'inserted':
      console.log('inserted');
    break;
  }
});

Describe the bug When using a table with a primary key and secondary index, WebSQL queries fail to execute on large-ish datasets.

SQLError {code: 5, message: "could not prepare statement (1 too many SQL variables)"}

Example With a table consisting of 2 indexes and 7500 records, the following error occurs with the WebSQL adapater during the initial connect:

_this._sql(false, "SELECT id FROM " + table, [], function (result) {

Error: SELECT data from Vehicles WHERE id IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, (7483) [392430, 392437, 392441, 392442, 392443, 392446, 392449, 392450, 392451, 392455, 392533, 392537, 392539, 392540, 392546, 392555, 392556, 392558, 392561, 392566, 392572, 392574, 392576, 392581, 392582, 392583, 392584, 392585, 392597, 392598, 392605, 392609, 392620, 392631, 392643, 392647, 392656, 392657, 392659, 392660, 392662, 392663, 392668, 392669, 392670, 392671, 392672, 392683, 392690, 392697, 392700, 392710, 392713, 392716, 392718, 392724, 392727, 392734, 392743, 392755, 392762, 392766, 392767, 392771, 392789, 392793, 392797, 392816, 392820, 392821, 392822, 392831, 392834, 392842, 392843, 392847, 392851, 392852, 392854, 392858, 392859, 392861, 392862, 392863, 392872, 392936, 392939, 392942, 392948, 392949, 392952, 392956, 392960, 392961, 392969, 392974, 392976, 392979, 392983, 392987, …] SQLError {code: 5, message: "could not prepare statement (1 too many SQL variables)"}

Expected behavior Expectation is for queries to execute correctly despite the data size and index count.

I'm using nanosql in my project to create a library that I then include into a different project.

When I do the tests on my library everything works fine. But when I include it into the other project there's this really weird issue. The setup is as follows:

• I use react-nanosql to react to onChange
• I have a table TABLE with COLUMN with a single row
• Within onChange I use a select query to get the new value
• The COLUMN value in that row starts of with 0

When I update the row, I can see a console.log showing that COLUMN has been changed to 1 The event passed into onChange is showing the same, with query.state being complete But the select within the onChange is showing the old value! It still shows 0!

This is where it gets really weird. If the mode is set to TEMP everything works. If the mode is set to PERM, but I'm testing just my library everything works.

The only time this doesn't work, is when I use the library within the other project, and the mode is PERM.

This is very hairy.

PS. The other project uses redux-persist with localforage

Would like to use nanosql with RocksDB, which is a successor of Leveldown. Wonder whether we could remove the leveldown dependency to further reduce package size.

Which version are you using? from @nano-sql/[email protected] upgrade to @nano-sql/[email protected]

Describe the bug Can't connect the exist database after upgraded, the nanoSql used in nodejs server, and use PERM mode store the data in file

Example Today I wanna use the nanoSql new feature select('total'), and then upgrade the module, BUT occur the failure! I change the nSQL().connect to nSQL().createDatabase, also occur error!

PS: I notice that it will run node-gyp to compile something when install the v2.2.3, but NOT when install the v2.3.2, Is new version missing some dependents against to the old version?

Hi, Scott. I'm using the latest version. In an earlier version I had set up 2 buttons like this:

$('#undo-btn').on("click", function(){
  nSQL().extend("<").then(function(response) {
    console.log(response) //<= If this is true, an undo action was done.  If false, nothing was done.
    if(response) {undoing = true};
  });
})

$('#redo-btn').on("click", function(){
  nSQL().extend(">").then(function(response) {
    console.log(response) //<= If this is true, a redo action was done.  If false, nothing was done.
    if(response) {redoing = true};
  });
})

These were working great prior to updating to the latest. I can confirm that changes have been made to rows in the (only) table in the database. This is logging the correct values on update...

nSQL("aniblocks").on('change',function(eventData) {
  console.log('modified: ',eventData.changedRows);
});

I set a breakpoint on nSQL().extend("<").then(function(response) { and took some screenshots for you to peruse.

Should the change listener receive the the id of, or an object containing the record that was reset as a result of an undo or redo? Seems like that would be really great info to have. Currently I'm having to do this:

An undo button listener:

$('#undo-btn').on("click", function(){
  SomeSQL().extend("<").then(function(response) {
    if( response ) {
      resetOnStateChange();
    }
    console.log(response)
  });
  SomeSQL().extend("?").then(function(response) {
    console.log(response)
  });
})

The resetOnStateChange function snags all the records because I don't know what record to get:

  SomeSQL('aniblocks').getView('list_all_blocks')
  .then(function(result, db){
    console.log(result);
    // do stuff with the data
  });
}

I have a change listener like:

SomeSQL("aniblocks").on('change',function(eventData) {
  console.log(eventData);
})

but it returns a set of empty arrays..

Describe the bug When creating nested AND / OR statements for WHERE, the search fails.

Example Works, but does not match my desired query:

[
    ['account_id', '=', this.account.id],
    'AND', 
    ['name', 'LIKE', `%${this.searchQuery}%`]
]

Does not work:

[
    ['account_id', '=', this.account.id],
    'AND', 
    [
        ['name', 'LIKE', `%${this.searchQuery}%`]
    ]
]

Does not work, but matches the final query desired:

[
    ['account_id', '=', this.account.id],
    'AND', 
    [
  	['name', 'LIKE', `%${this.searchQuery}%`],
  	'OR',
  	['vin', 'LIKE', `%${this.searchQuery}%`]
    ]
]

Expected behavior I would expect nested operators to correctly resolve themselves. For example, I would expect the final code example above to resolve to a similar SQL statement as:

SELECT * FROM Vehicles WHERE account_id = 1 AND (name LIKE "%chevy%" OR vin LIKE "%chevy%")

when the following function gets called the result is an array containing 2 identical inserts.

function addNewBlock(obj) {
  console.log('ran addNewBlock. obj: ',obj);
  nSQL('aniblocks')
  .doAction('add_new_block',{aniblock:obj}).then(function(result, db) {
    console.log(result);
    return db.getView('get_block_by_blockID',obj);
  }).then(function(result, db) {
    console.log('new block: ',result);
    return result;
  });
}

This is how nano-sql is being set up in that file:

nSQL('aniblocks')
.model([
  {key:'id',type:'uuid',props:['pk']},
  {key:'blockID', type: 'string', props: ["idx"]},
  {key:'blockInnerHTML', type: 'string'},
  {key:'foDom', type: 'string'},
  {key:'blockStartTime', type: 'float'},
  {key:'blockTimeScale', type: 'float'},
  {key:'title',type:'string'},
  {key:'type',type:'string'},
  {key:'settings',type:'map', default: null},
  // {key:'funcStr',type:'string', default: null},
  // {key:'removeSelector',type:'string', default: null},
  {key:'timelineData',type:'blob'}
])
.actions([
  {
    name: 'add_new_block',
    args: ['aniblock:map'],
    call: function(args,db) {
      console.log('ran add_new_block. args: ',args);
      return db.query('upsert',args.aniblock).exec();
    }
  },
  {
    name: 'update_block',
    args: ['aniblock:map'],
    call: function(args,db) {
      var D = args.aniblock;
      // console.log(args.aniblock);
      return db.query('upsert',D).where(['blockID','=',D.blockID]).exec();
    }
  },
  {
    name: 'delete_block',
    args: ['aniblock:map'],
    call: function(args,db) {
      var D = args.aniblock;
      return db.query('delete',D).where(['blockID','=',D.blockID]).exec();
    }
  }
])
.views([
  {
    name: 'get_block_by_blockID',
    args: ['blockID:string'],
    call: function(args,db) {
      console.log('ran get_block_by_blockID. args: ',args);
      return db.query('select').where(['blockID','=', args.blockID]).exec();
    }
  },
  {
    name: 'list_all_blocks',
    args: ['blockID:string'],
    call: function(args,db) {
      console.log('ran list_all_blocks');
      return db.query('select').exec();
    }
  }
])
.on('error', function(eventData){
  console.log(eventData);
})
// .config({persistent:true})
.connect().then(function(result,db){
  connected = true;
});

If I run list_all_blocks both of the items are returned. Any idea what I'm doing wrong?

Ran build in my Electron project and now getting this error:

Uncaught Error: The module '/Users/username-was-here/Documents/project-name-was-here/build/node_modules/leveldown/build/Release/leveldown.node' was compiled against a different Node.js version using NODE_MODULE_VERSION 48. This version of Node.js requires NODE_MODULE_VERSION 53. Please try re-compiling or re-installing the module (for instance, using npm rebuild ornpm install).

This is the first time I'm seeing this.

Using: node v6.9.5 npm version 3.10.10

Went back to 0.4.5 and the error went away. Would love to up to a later version.

Hello this looks great, thanks very much. I'm using the levelDB setting - as I'd like to save a bunch of records via Node.js - then copy it all over to my server for read only access from my serverless single page javascript app.

Look like I'll be able to do that nicely with this - but I'm also planning to use protocol buffers instead of json, as I have a lot of data - I've seen some other Node.js libraries that save to leveldb with this - and I think I can just decode/encode with yours - but have you thought of adding support for this?

Thanks again.

It is not possible to select values with type date, if the value is undefined.

On selection the mutateRowTypes function is called. In this function columns with type date will be converter to ISOString on selection: new Date(useObj[m.key]).toISOString();

If useObj[m.key] returns undefined, an error is thrown: RangeError: Invalid Date

See: https://github.com/only-cliches/Nano-SQL/blob/af74705e3fc4be6e65c0e4044f7dc7c5b745886c/packages/Core/src/utilities.ts#L437

Is there a reason why an ISODate is returned instead of Date type? I think there should be a conversion to ISODate on insert and a conversion to Date on select.

If I'm wrong, please insert an undefined check before using new Date()

Meanwhile I will try to use a "custom type" handling

            types: {
                "date": {
                    onInsert: (colValue) => colValue ? new Date(colValue).toISOString() : undefined,
                    onSelect: (colValue) => colValue ? new Date(colValue) : undefined
                }
            }

(Btw: The interface describes onInsert and onSelect, but I cannot find any use of onInsert?)

Im using nanosql with IndexedDB "@nano-sql/core": "^2.3.7",

Which version are you using? ^2.3.7

Describe the bug After any edits to a row in the database, it logs/backs up the entire row. For example, I have a "post" object that I want to add likes to. I do so, but it creates a whole new entry in "c1f7-5985"'s log file with the entire row. I only need to change it, not store another version. Nowhere have I stated that it should do this. This is also the same for other things like user data (separate tables).

E.g. when spamming like/unlike, it adds to the file as such

{"id":4,"text":"Well, how do YOU eat cheese?","creator":1,"created":1646029794133,"likes":[1],"repliesLastID":2,"replies":[{"id":0,"author":2,"text":"I like to eat cheese with my mouth, personally.","likes":[]},{"id":1,"author":1,"text":"I find that quite odd, past me.","likes":[1]},{"id":2,"author":2,"text":"I still agree with my statement about eating cheese with my mouth","likes":[]}]}:1,4,82445,391,2954716879�{"id":4,"text":"Well, how do YOU eat cheese?","creator":1,"created":1646029794133,"likes":[1,2],"repliesLastID":2,"replies":[{"id":0,"author":2,"text":"I like to eat cheese with my mouth, personally.","likes":[]},{"id":1,"author":1,"text":"I find that quite odd, past me.","likes":[1]},{"id":2,"author":2,"text":"I still agree with my statement about eating cheese with my mouth","likes":[]}]}:1,4,82862,393,3960410894�{"id":4,"text":"Well, how do YOU eat cheese?","creator":1,"created":1646029794133,"likes":[1],"repliesLastID":2,"replies":[{"id":0,"author":2,"text":"I like to eat cheese with my mouth, personally.","likes":[]},{"id":1,"author":1,"text":"I find that quite odd, past me.","likes":[1]},{"id":2,"author":2,"text":"I still agree with my statement about eating cheese with my mouth","likes":[]}]}:1,4,83281,391,397385191�{"id":4,"text":"Well, how do YOU eat cheese?","creator":1,"created":1646029794133,"likes":[1,2],"repliesLastID":2,"replies":[{"id":0,"author":2,"text":"I like to eat cheese with my mouth, personally.","likes":[]},{"id":1,"author":1,"text":"I find that quite odd, past me.","likes":[1]},{"id":2,"author":2,"text":"I still agree with my statement about eating cheese with my mouth","likes":[]}]}:1,4,83697,393,3445040025�{"id":4,"text":"Well, how do YOU eat cheese?","creator":1,"created":1646029794133,"likes":[1],"repliesLastID":2,"replies":[{"id":0,"author":2,"text":"I like to eat cheese with my mouth, personally.","likes":[]},{"id":1,"author":1,"text":"I find that quite odd, past me.","likes":[1]},{"id":2,"author":2,"text":"I still agree with my statement about eating cheese with my mouth","likes":[]}]}:1,4,84116,391,1107176446�{"id":4,"text":"Well, how do YOU eat cheese?","creator":1,"created":1646029794133,"likes":[1,2],"repliesLastID":2,"replies":[{"id":0,"author":2,"text":"I like to eat cheese with my mouth, personally.","likes":[]},{"id":1,"author":1,"text":"I find that quite odd, past me.","likes":[1]},{"id":2,"author":2,"text":"I still agree with my statement about eating cheese with my mouth","likes":[]}]}:1,4,84533,393,4220412814�{"id":4,"text":"Well, how do YOU eat cheese?","creator":1,"created":1646029794133,"likes":[1],"repliesLastID":2,"replies":[{"id":0,"author":2,"text":"I like to eat cheese with my mouth, personally.","likes":[]},{"id":1,"author":1,"text":"I find that quite odd, past me.","likes":[1]},{"id":2,"author":2,"text":"I still agree with my statement about eating cheese with my mouth","likes":[]}]}:1,4,84952,391,4210006312�{"id":4,"text":"Well, how do YOU eat cheese?","creator":1,"created":1646029794133,"likes":[1,2],"repliesLastID":2,"replies":[{"id":0,"author":2,"text":"I like to eat cheese with my mouth, personally.","likes":[]},{"id":1,"author":1,"text":"I find that quite odd, past me.","likes":[1]},{"id":2,"author":2,"text":"I still agree with my statement about eating cheese with my mouth","likes":[]}]}:1,4,85369,393,569378032

You see, that's way longer than it needs to be.

Expected behavior For it to just update the row instead of back it up every time.

Just came across this project and it looks absolutely amazing! Works out of the box and beats many other libraries on benchmarks while also having extensive docs.

I was wondering if this project is still maintained as I see the last push is from 2 years ago, or if there's any way I can get involved to keep it alive.

Which version are you using? version 2.3.7

Describe the bug When using a freshly created DB, everything seems to work, but as soon as I kill node with Ctrl + C and restart the server, all queries for fetching data from tables results in the following error:

C:\repos\identity-hub\packages\implementation\node_modules\snap-db\bin\database.js:699

    throw new Error("Error parsing log file!");
    ^

Error: Error parsing log file!
    at processLog_1 (C:\repos\identity-hub\packages\implementation\node_modules\snap-db\bin\database.js:699:31)
    at ReadStream.<anonymous> (C:\repos\identity-hub\packages\implementation\node_modules\snap-db\bin\database.js:755:21)

Expected behavior Queries against established tables with data that previously was present and queriable should remain so.

Example I can get a copy of the repo up soon, but here are the relevant code sections: export default class Storage {

export default class Storage {

  constructor(did, options = {}){
    this.did = did;
    this.dbName = did.split(':').slice(0, 3).join('-');
    this.ready = nano().createDatabase({
      id: this.dbName,
      mode: 'PERM',
      tables: this.tables = [
        {
          name: 'stack',
          model: {
            "id:string": { pk: true, immutable: true },
            "file:string": { immutable: true }
          }
        },
        {
          name: 'profile',
          model: {
            "id:string": { pk: true, immutable: true },
            "data:object": {},
            "signature:object": {}
          }
        },
        {
          name: 'permissions',
          model: {
            "id:string": { pk: true, immutable: true },
            "schema:string": { immutable: true, notNull: true },
            "data:object": { immutable: true },
            "signature:object": {}
          },
          indexes: {
            "schema:string": { ignore_case: true }
          }
        },
        {
          name: 'collections',
          model: {
            "id:string": { pk: true, immutable: true },
            "type:string": { immutable: true },
            "nonce:string": { immutable: true },
            "schema:string": { immutable: true, notNull: true },
            "root:string": { immutable: true },
            "parent:string": { immutable: true },
            "tags:array": {},
            "data:object": { immutable: true },
            "signature:object": {}
          },
          indexes: {
            "schema:string": { ignore_case: true }
          }
        },
        {
          name: 'actions',
          model: {
            "id:string": { pk: true, immutable: true },
            "nonce:string": { immutable: true },
            "schema:string": { immutable: true, notNull: true },
            "root:string": { immutable: true },
            "parent:string": { immutable: true },
            "data:object": { immutable: true },
            "signature:object": { immutable: true }
          },
          indexes: {
            "schema:string": {ignore_case: true}
          }
        }
      ]
    })  
  }

  async txn(fn){
    return this.ready.then(async () => {
      await nano().useDatabase(this.dbName);
      return fn(nano);
    });
  }

}

ClassInstance.txn(db => db('collections').query('select').exec()).catch(e => console.log(e));

//  ^ this call fails

Which version are you using? "@nano-sql/core": "^2.3.7" "snap-db": "^1.1.6"

Describe the bug Query "select" throw exception

Expected behavior Get data from specified table

Example `const dbList = nSQL().listDatabases();

console.log('dblist', dbList); //-> display one database : "organizer"

nSQL().useDatabase("organizer");

nSQL("watchings").query("select").exec().then((rows) => { console.log(rows) });`

strange fact: upsert works well.