clarification on merge on update about seneca-store-test HOT 10 CLOSED

merge is the correct behavior - so nosql stores like level will need to do a load first

this is often no desired, so all stores should support a "merge" option in their settings:
merge:true means merge data
merge:false means override data

also allow merge$ parameter in individual operations for custom behaviour
{id$:x,merge$:false,...}

from seneca-store-test.

just to clarify: the merge option defaults to true?

from seneca-store-test.

yes

from seneca-store-test.

@rjrodger another quick clarification: should the object returned after the save already be the merged one or just a copy of the params passed in to the save?

from seneca-store-test.

the merged one - we always want to result to be as update to date as possible

from seneca-store-test.

@rjrodger I'm fixing seneca-mem-store to make it follow new tests, but I just noticed that seneca itself doesn't send to the store attributes starting or ending with $ on save, except from id$.

Do you want me to provide a PR to seneca or do you want to change your decision on this?

from seneca-store-test.

$ attributes are special - reserved for use by seneca, so are never persisted

from seneca-store-test.

@rjrodger sorry, I wasn't clear in my comment.

In your initial response to this issue you introduced the merge$ option for an individual save operation, however at the moment seneca strips all the attributes starting or ending with $ and thus merge$ doesn't reach the store that is in that way unable to implement the correct behaviour.

We may want to "not introduce" the merge$ option on individual option or amend seneca to not strip $ attributes and leave that to the store (or just allow the merge$ option to pass through).

Which one do you prefer?

Please note that the latter would be a breaking change since current stores that don't follow this rule may end up storing the $ attributes.

from seneca-store-test.

We'll add merge$ as an individual option - and accept the pass through problem, as it is relatively harmless.

In general this also raises the question of what a store should do with attributed it does not recognise.
So two new rules for stores:

1. never store $ attributes (existing stores will need to be updated, but not urgent)
2. ignore attributes you don't know about (applies to SQL stores mostly - mongodb will just store it anyway)

from seneca-store-test.

@rjrodger About $ attributes: if I understand correctly they are already filtered by seneca itself except for id$ (hence the need for https://github.com/senecajs/seneca/pull/217/files, now merged)

from seneca-store-test.