[Mono-list] DbDataAdapter.Fill patch

[A Rafael D Teixeira]

>From: Aleksey Demakov <avd@openlinksw.com>
>To: Alan Tam <Tam@SiuLung.com>
>CC: mono-list@ximian.com
>Subject: Re: [Mono-list] DbDataAdapter.Fill patch
>Date: Tue, 25 Feb 2003 15:24:56 +0600
>
>So what's wrong with it? I think that a DataAdapter at one time
>should update only one table. It's absolutely wrong to iterate
>through all the tables in the DataSet because the DataAdapter
>contains only one set of update commands while different tables
>require different commands.
>
>Regards,
>Aleksey
>
>Alan Tam wrote:
>>The bottom half of the patch has been applied. Thank you.
>>
>>For the upper half, we may need more discussion. As far as I've observed, 
>>the
>>patch changes the code to simulate Microsoft behavior, which seems to be a
>>wrong behavior. I wonder if we should follow suit.
>>
>>Regards,
>>Alan
>>
>>----- Original Message -----
>>From: "Aleksey Demakov" <avd@openlinksw.com>
>>To: <mono-list@ximian.com>
>>Sent: Wednesday, January 22, 2003 4:37 AM
>>Subject: [Mono-list] DbDataAdapter.Fill patch
>>
>>
>>
>>>Hi all,
>>>
>>>I've found that the DbDataAdapter.Update (DataTable dataTable)
>>>and Update (DataSet dataSet, string sourceTable) methods
>>>iterate through all tables of the given dataSet and try
>>>to update them with this DataAdapter. I believe that
>>>this is incorrect.
>>>
>>>The dataSet can contain multiple DataTables which are
>>>Filled using different DataAdapters with different
>>>select/insert/delete/update commans. Consequently
>>>one DataAdapter cannot be be able to perform all the
>>>needed updates.
>>>
>>>Unfortunately, the .NET docs are silent about this
>>>issue. But I believe that DbDataAdapter.Update methods
>>>should be symmetric to Fill methods. So as Fill (DataSet)
>>>method fills only one DataSet table with default
>>>name "Table", the Update (DataSet) method should
>>>only update default table. And Update (DataSet, string)
>>>method should only update the specified table.
>>>
>>>The attached patch fixes also another problem.
>>>The original code might pass a null DataTableMapping
>>>value which is then used to create a RowUpdatingEventArgs
>>>instance. So RowUpdatingEvent handler (for instance
>>>CommandBuilder) could get null DataTableMapping which
>>>might be unexpected. The patch makes sure that a non-null
>>>DataTableMapping is passed.
>>>
>>>Regards,
>>>Aleksey
>>>

I think nobody here has used VS.NET wizards, extensively. So let me share my 
experience...

The wizards simply won't allow anyone to make a DBAdapter updatable, if you 
bring it something more complex than a simple select from where it can find 
all the mappings automatically.

It's not that we can't make our implementation able to handle more general 
situations, but MS directs developers in that way and so they may have 
designed their classes to support ONLY that way of doing things, and 
compatibility is still a goal of this project, I think.

Show me MS classes doing that kind of multiple table updating, WITHOUT 
having to dynamically alter what the "Initialize()"-time code has set. 
Without that I think it's better to handle only single table updates.

Oh, yeah: It is an ugly picture seeing each of my Web Service components in 
design mode sporting some dozens of DataAdapters, but that is the way with 
MS Tools, and people from Windowsland, like me, will find it 'natural' and 
expect it to be so in Mono, too.

Best regards,

Rafael Teixeira
Brazilian Polymath
Mono, MonoQLE Hacker






_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail