-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: update row #5
Comments
Hey @DJSundog, you already can! The returned results are proxies and are thus reactive :) Try: db.cars.where('model').is('F5').getFirst().model = 'F150'
db.cars.where('year').isLessThan(2000).get().forEach(car => car.needsSmogTest = true) For the first one, though, I’d write it more defensively as: const theFirstF5 = db.cars.where('model').is('F5').getFirst()
if (theFirstF5) theFirstF5.model = 'F150' If we wanted to avoid having to write that out in two lines (i.e., support chaining when there is no result, ala optional chaining) we could modify the behaviour of So, instead of throwing, the assignment would simply set the model property on a simple empty object, thereby effectively ignoring it. This would also be consistent with how the results of Thoughts? :)
(db.cars.where('model').is('F5').getFirst() ?? {}).model = 'F150' |
Also, this makes me realise that we need a section along the lines of “Updating data” in the readme. I’ll wait for your thoughts and then possibly open two internal issues regarding this:
|
Hey, thanks - I just flipped some of my code around and can confirm that it works as you describe (not that I am surprised or anything). That definitely makes things easier! I think returning undefined on getFirst() et al is semantically nicer than returning an empty object, so that a check for undefined acts as "no such record", but I suppose checking for the truthiness of any property of the returned object would be semantically the same for most use cases. Adding more docs about the results being reactive would be welcome - I was mistakenly assuming I'd need to write modified data back to the table manually, so this is much nicer - thanks! |
Tracking internally at:
|
Use case:
If we assume a JSDB table initialized as
I would like to be able to update data in the table, either by querying for row index/indices, like
or by having access to an update method, like
As an alternative to the second version, I'd be fine with having the update(newData) method hanging off the query pre-get (so,
db.cars.where('model').is('F5').updateFirst(newData)
and the like.Thoughts?
The text was updated successfully, but these errors were encountered: