Skip to content
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

When updating a document entry, existing unmapped data gets removed #9

Closed
mylemans opened this issue Sep 19, 2013 · 4 comments
Closed

Comments

@mylemans
Copy link

Scenario:

You have a document with field A and B.

I then save away a document.

Then I modify my 'model' so that it has field A and C.

I retrieve the existing document, A will be filled, C will be empty, and then save it away again as-is (as I received it in the first place)

Result: It'll store A and an empty C field, but the contents of the B field will be have been removed.

Imho, there should be a way to make it so that existing 'unmapped' data can be kept when updating an entry. Either by default or optionally.

We're actually considering using this for a 'cloud' storage solution (of 'data', not files) but that would require YesSql to be able to update a record with new data without removing the unmapped data.

For example: one of the 'users' could be running on an 'old' model, without this ability any 'old model' user would be able to 'remove' unmapped field data.

It would kinda beat the cloud concept if we'd have to update all 'clients' at the same time to prevent this kind of loss.

AimOrchard here btw ;)

@sebastienros
Copy link
Owner

I think there is a good way to do that, by just keeping the field around here, and adding [Obsolete] on it. This is exactly what it means. And you can decide at some point to drop it.

The changes required otherwise would be huge !

@mylemans
Copy link
Author

But required if you want to match feature wise.

Also your suggestion doesn't really resolve this issue.

Example: You got 2 'clients' that use a YesSql powered backend.

You then do an update to the model: you add in an additional field (your Obsolete remark is only relevant when you want to 'remove' a property).

You HAVE to shut down ALL clients (make sure nobody is using the old model) and only after having updated a client can you turn it back on. You CANNOT allow old clients to stay connected or you'll risk loss of data.

Why?

Well assume client A updates first, while client B is still running using the 'old' model.

Client A is updated, gets turned on, and instantly starts adding new documents or modifies existing ones, adding in the data from new properties that were added to the model.

In the meanwhile, client B is still not updated and retrieves ones of the documents that client A created or 'edited', and changes on of the fields that it can access and then saves it.

Result: The additional data stored by client A will be gone.

This is a big issue if you want YesSql to be useable from multiple 'locations': In a 'cloud like' setup, you simply cannot afford to be required to take 'everything' offline whenever you add something new.

Compare it to (for example) regular MSSQL NHibernate usage. If you would do the same 'test' with regular records, the unmapped data would not have been lost at all, as NHibernate only stores the fields it is 'aware' of (it cannot 'update' the fields that it isn't aware of, so nothing can be lost).

Another example is MongoDB that has a way to update specific fields, while leaving other ones untouched.

The changes required might be huge, but in my opinion required.

Hope my examples are sufficient and you understand the issue.

@sebastienros
Copy link
Owner

Sorry. too many things to deal with right now, will answer in a few, thanks for you patience

@sebastienros
Copy link
Owner

I think it should work with the new version. The json document is untouched.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants