A Rafael D Teixeira
Fri, 14 Dec 2001 10:47:26 -0200
>From: Rodrigo Moya <email@example.com>
>* DataSet's: there's no such thing in libgda, but adding this is just a
>matter of creating a new GObject class to libgda, since all the needed
>stuff (XML for data transfer, offline, etc) is already available in
>libgda or can easily be implemented.
Dataset are built as a quite separate layer above the rest of the classes in
ADO.NET, and I think we should replicate this pattern not tying it directly
to lidgda (ADO.NET Datasets use DataReaders to populate themselves and
DataCommands to make them updatable).
>The only thing I think won't be easy to implement is read-write
>datasets. That is, I can't imagine why somebody will get a picture of
>an entire database, modify it for a day, for instance, and then put it back
>to the database.
Itīs not easy but itīs worth because it simplify enormously the application
developer work. I know it firsthand because I have constructed thousands of
forms/web pages with VB & ADO, and itīs a lot easier to work with ADO.NET
>This can be a nightmare if the database has been modified by other
>people. But, well, it's not something impossible to
>implement, so if it's needed, it can be added.
This nightmare comes if you donīt design properly your application...
If you need to guarantee consistency during a long-time "user
transaction/interaction", you MUST put locks to work.
My personal design rule is: if it takes less than a second use the
appropriate transaction level to put the burden on the server to manage the
locks, else if it takes more than a second (some batch processing, probably)
or is interactive (where you canīt know how long will be the waiting time)
use logical locks (especialized tables used as applicationīs internal
>* XML: we are using custom XML formats for representing SQL queries
>(XML queries we call them) and an entire database (GdaXmlDatabase), so
>maybe >there can be a problem with this custom format if it is to be shared
>with other apps.
>We were thinking on switching to the XML DTDs defined in
>http://www.odmg.org. Maybe we should support various formats for all
First make these clearly an extension, keeping it on a Mono.Data namespace.
Second make it pluggable: to our extended ADO.NET classes pass a
Mono.Data.Query object that is a abstract class, not tied to XML, and derive
a ODMGQuery class from it, because that way we can accept other dialects,
and maybe even objects encapsulating W3C XQuery querys.
Join the worlds largest e-mail service with MSN Hotmail.