Atomicity of changeset

[mkr...@trialfire.com]

At what level are changesets atomic? For example if there is a typo somewhere in one  changeset will the changeset rollback?

[Oleksii Iepishkin]

At the same level as mongodb is. Batch updates are not atomic. More info could be found here:

http://docs.mongodb.org/manual/tutorial/isolate-sequence-of-operations/

There is no rollback in mongeez. But you may suggest how it should be implemented (and even submit pull request!)

On Mon, Aug 12, 2013 at 2:23 PM, <mkr...@trialfire.com> wrote:

At what level are changesets atomic? For example if there is a typo somewhere in one  changeset will the changeset rollback?

--
You received this message because you are subscribed to the Google Groups "Mongeez Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongeez-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Oleksii Iepishkin]

Sorry I didn't answer your question about typos.

There is no concept of atomicity in mongeez. If you make a typo in your mongo command it's execution will just fail.

My personal opinion - it doesn't make sense to try to do rollbacks on mongodb. Usually mongo databases are huge. And changes that we had to do in our databases where mostly data manipulation like change one value with another of prepopulate a new field. If such process fails how do you know where to get old value of a field. If you screw the process you have to have a backup to restore your DB.

But I'm open to discuss my opinion.

[mkr...@trialfire.com]

Ok so I did the following experiment.

<changeSet changeId="ChangeSet-5" author="max">

        <script>

            db.testmongeez2.insert({"Name" : "This should save", "Location" : "NYC"});

            db.testmongeez3.insertx({"Name" : "Will this be here?", "Location" : "NYC"});

        </script>

    </changeSet> 

Notice the intentional type-o in the second insert. The entire changeset is run and you get com.mongodb.CommandFailureException which makes sense, but the first statement in the changeset still executes fine, resulting in a partial change. Stuff like this is scary because it can be difficult to recover from such errors (the above case is simplistic but you can imagine a scenario with multiple changesets each dependent on previous ones.

Anyway, I realize that mongo doesnt have "transactions" and "rollbacks" in the SQL sense. Just wondering if there's any way to validate statement before permanently executing them and thought it would be a worthwhile discussion. 

P.S. I think mongeez is awesome  - we've been using it for a week now and it's great. We use it with Play 2 for Scala so I can contribute to the samples on github. One thing is that I wish there wasn't a dependency on Spring :(

[David M. Carr]

As for wishing there wasn't a dependency on Spring, I agree with you (despite my primarily using Mongeez in a Grails environment, where Spring is a given).  There's been an issue requesting it (but no one volunteering to work on it) for quite a while now.

https://github.com/secondmarket/mongeez/issues/5

If I were working on it, I'd tend toward the following approach:

- Convert the build for the module, as-is, from Maven to Gradle (including TravisCI support)

- Split the existing code as-is into mongeez-core and mongeez-spring subdirectories (each a gradle project)

- Various tweaks to move more into core so it's a usable component on its own

- Release the changes as either 0.10.0 or 1.0.0, definitely not 0.9.4, as this is definitely a large compatibility break, even for pre-1.0 versioning

While a move from Maven to Gradle isn't strictly necessary, I strongly prefer it these days, and find its multi-project support to be far easier to use and understand than Maven's.  If that direction sounds reasonable to Oleksii Iepishkin, I'd be willing to start on the series of pull requests sometime next week.

David M. Carr

da...@carrclan.us

--
David M. Carr
da...@carrclan.us