[Mono-list] Mono.ADO.Net

[A Rafael D Teixeira]

>From: Rodrigo Moya <rodrigo@ximian.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 
Datasets.

>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 
semaphores).

>* 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
>this?

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.

Happy Hackings

Rafael Teixeira
Brazilian Developer




_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com