[Mono-list] Re: Mono ADO.Net

[Robert Deviasse]

>yes, and it is a nice idea worth supporting it in gnome-db.
>I'm only worried about the data loss that (I guess) users
>will encounter.
>

My understanding of the DataSet is a bit different. From my
understanding it behaves as if it were live connected. Essentially,
it virtualizes the connection, caching, can transaction management
at a higher level than ODBC or other APIs.

This is not a new issue. File systems like NFS and AFS do something
similar without real data loss. Version control systems that have
multisite capabilities also handle this daily.

>yes, that's why I said it might be a nightmare, because users
>will be losing their modifications too often (in a multi-user,
>ever-changing database). As you say, it can be really easy to
>just discard
>modifications for rows/fields that have already been changed by someone
>else, but this won't help too much that user.
>

How different is this from normal multi-user database access?

Things change during transactions. If you don't want them to
change, you lock them while you're using them. If all you want
is consistency of input, you can lock what you need, take a
snapshot (i.e. cache read data), unlock them, then do what
you want.

The main feature (from what I understand) if ADO.NET is that
you have more flexibility on how you do your DataSet caching.
Since DataSets appear to look the same when there's no caching
and when there's full caching, you can design your program one
way and then change it later without too many code changes.

This paper gives more information about what I'm talking about:
http://www.develop.com/conferences/conferencedotnet/materials/A9.pdf

Since I'm not a database expert or ADO.NET expert, I might be
missing the point you're making or overlooking some design
flaw that negates something I'm saying. Take what I say with
a grain of salt.


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com