Hi everybody!

I am newby to DO, performing some analisys on using DO in field of GIS development.So i am sorry for stupid questions.

Here is my problem using DisconnectedState:

I have a collection of entities. User selects one and modifies its properties using form. How can i handle entity to discard changes when user selects Cancel button? What would be the best pattern to handle both scenarios "Add New/Cancel, Edit/Cancel"?

Is it possible to perform rollbacks on disconnected transactions? Or should I reset disconnected Session and perform reload of entire DB (which i dont want)? If that is the case is it possible to keep entities form previous session and reload only the one that was modified and canceled? Is it there any support for creating Copyes of Entities? Is there any other way to isolate Entity that is being modified? Is there any way to share same entity among several sessions (connected and disconected)

Best Regards, Sandi

This thread was imported from our support forum. The original discussion may contain more detailed answer. Original topic by Zgckula.

asked Mar 03 '10 at 10:16

Editor's gravatar image

Editor
46148156157


One Answer:

There are two options:

  • DisconnectedState.CancelChanges() invocation makes it to forget all the cached state & operation log.

  • Transaction.Open for Session with attached DisconnectedState opens a local transaction for DisconnectedState. So if it's cancelled, the changes made in it will be rolled back. DisconnectedState fully support nested transactions.

So you can consider:

  • AcceptChanges\CancelChanges commits or rollbacks a top-level transaction for the whole DisconnectedState;

  • Transaction.Open opens a nested one; nesting level is unlimited.

It's also important to know how DisconnectedState attachment affects on real database-level transactions:

  • Obviously, real database transactions can be created only inside DisconnectedState.Connect() block and AcceptChanges() call.

  • A single AcceptChanges() call is executed in a single real database transaction

  • Currently a single Connect() call may lead to creation of a single transaction at max, which will be closed (committed, but this is actually not important, since only read-only operations can happen there) on either disconnection or detachment of DisconnectedState.

"Currently" here implies that shortly we'll add more options allowing to control this. E.g. in some cases it might be desirable to create a single transaction for each local top-level transaction inside Connect() blocks.


Now exact answers:

> How can i handle entity to discard changes when user selects Cancel button? What would be the best pattern to handle both scenarios "Add New/Cancel, Edit/Cancel"?

I'd use transactions (Transaction.Open).

Global Apply/Commit buttons may reply on AcceptChanges/CancelChanges.

> Is it possible to perform rollbacks on disconnected transactions?

Yes (described above).

> Or should I reset disconnected Session and perform reload of entire DB (which i dont want)?

No, you shouldn't. Err... I made a mistake about CancelChanges: it makes DS to forget only operation log an modifications you've made. All the data cached in DisconnectedState stays there.

> If that is the case is it possible to keep entities form previous session and reload only the one that was modified and canceled?

This is not a case. But if you need to keep some cached state or attach it to two or more Sessions, you can clone it using .NET serialization.

We have a nice helper class for this - Cloner (in Core). An example:

var disconnectedStateCopy = Cloner.Default.Clone(disconnectedState);

> Is it there any support for creating Copyes of Entities?

What exactly do you mean? Identity must work anyway, so you can't copy an entity to create its another version for e.g. different editor (i.e. to produce something like modifiable view of entity). But you can copy the whole DS, attach it to another Session and get the clone there.

Another possible reason is to really clone some Entity - e.g. to create a copy of Task from its template (Task as well). We don't provide any default implementation here, but DO supports serialization (actually, beta - i.e. this isn't thoroughly tested), so you can use nearly the following code to create a copy:

Task newTask;
using (var serializationScope = (new SerializationContext(SerializationKind.ByValue)).Activate()) {
  newTask = Cloner.Default.Clone(taskTemplate);
}

> Is there any other way to isolate Entity that is being modified?

No way to isolate a single one, but it's easy to isolate the whole graph.

> Is there any way to share same entity among several sessions (connected and disconected)

What does this exactly mean?

  • It's impossible to share the same entity state. The state is always isolated.

  • By any other mean it is shared.

Actually, there is a related question: how to properly deal with Sessions in e.g. MDI UI. I'll write a reply on this shortly.


Forgot to add: currently you must call Session.NotifyChanged() method manually after rollbacks \ CancelChanges, or simply rebind the UI displaying affected objects (~ var tmp = primaryControl.DataContext; primaryControl.DataContext = null; primaryControl.DataContext = tmp;).

This will be fixed shortly.

Issue: http://code.google.com/p/dataobjectsdot ... ail?id=616

answered Mar 03 '10 at 10:46

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412

Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

Subscription:

Once you sign in you will be able to subscribe for any updates here

Tags:

×569

Asked: Mar 03 '10 at 10:16

Seen: 2,297 times

Last updated: Mar 03 '10 at 10:16

powered by OSQA