Delete Column During Update

[rj919]

Since the .update() method calls .mergeObj(), there does not seem to be any way to delete a column from a record in taffy once it is created. I have also tried to use function(){ delete this[column]; return this; } but this seems to have no effect ... in fact it doesn't even throw an error.

A. Is this intentional? I noticed that .merge() in lodash also lacks a method to remove a key from an object. Is best practice in nosql inspired databases not to remove columns?

B. Without the ability to delete a column, what is the best practice to ensure that this record does not appear in subsequent .filter() calls?

PS. I have cross-posted this issue on Stackoverflow

[typicaljoe]

Can you help me understand your use case for removing columns? I could see it potentially being nice to keep your data structures clean, but not a breaking lack of feature. The recommended solution would be to either to remove the offending record entirely or set the offending column to a negative value and filter it out.

I did a little poking around and I'm about 90% sure you can use .extend() to add a custom method to remove the record in its current form and insert a new copy with the column(s) removed.

[rj919]

Yes. Remove + Insert = Update. That sounds like the best way to delete columns... and it will likely work for my use case as well.

I have been putting together an npm module which adds a sync method to Taffy for synchronizing data with a REST API. After working with PouchDB, I wasn't entirely pleased with the overhead it requires, and I didn't see anything like this for Taffy, so thought I'd wrap a function around Taffy which extends Taffy to include client server data synchronization and turn it into a module for others to use as well.

However, technically .update() in Taffy == merge and Remove + Insert == overwrite. So, since my wrapper uses onUpdate, onInsert and onRemove settings, there is the potential edge case that two transactions (DELETE and POST) will not equal one update transaction (PUT) if the triggered processes are non-blocking.

I haven't tested this yet to see... but if it is an issue, your suggestion to use extend to build a special method for this overwrite edge case may be the best option rather than adding overwrite as an option to .update(). Thanks.

[typicaljoe]

So given your use case what I'd suggest not using the native onUpdate / onRemove methods and extend (replace) both .remove() and .update() with your own custom methods that do there own handling for changes (trigger calls to the REST api). That way you could have update always do a remove, insert (or make it smart enough to do it contextually based on what is changing). Then adding taffy and your custom script would give you the intended effect.

[rj919]

That's a good idea.

I've been thinking about creating a new method called .overwrite() which can be called instead of .update() if the goal is to delete columns or otherwise completely replace a record. This would allow me to map .update() -> onUpdate to 'PATCH' and .overwrite() -> onOverwrite to 'PUT' without interfering with the normal operations of update(), insert() or remove(). Since update and PATCH can both function as a merge (non-delete upsert) request, it becomes 'safer' for use cases where records which could be edited from multiple sources might create an inconsistent state at the cost of not being able to delete columns, while at the same time allowing a true PUT replacement to occur when circumstances deem it necessary at the cost of potential inconsistency.

It seems to me that this approach creates the smallest footprint on Taffy's existing architecture while achieving the goal of my use case. Neither insert nor remove need be tinkered with... overwrite would simply call both with the normal event triggers disabled. Once the record has been recreated, it would call its own event trigger which prompts a sync (PUT) request if auto-synchronization is enabled.

Since I am only creating overwrite() for the purposes of mapping PUT, I'm not sure that there is a need to mess with all the settings to have a real onOverwrite trigger... so what I have in mind is merely an internal trigger at the moment.