[.NET] typed dataset hell

[whoami]

Ik weet weer waarom ik (typed) datasets haat...

Ik heb een typed dataset, en die dataset heeft een aantal typed datatables.
uit een van die typed datatables verwijder ik een datarow.

Op een gegeven moment heb ik echter het Id nodig van die verwijderde row.
Als ik het Id zo opvraag:

code:

myDeletedDataRow.Id

dan krijg ik een exception dat ik de waarde niet kan uitlezen, omdat de row verwijderd is.

Ok, dan kan ik de Id opvragen van de 'Original' DataRowVersion. Echter, hier zit m'n probleem.
Als ik dit doe, dan moet ik de 'physical name' gebruiken van de column-name in de DB, en dat wil ik niet.
Hoe kan ik de waarde van dat Id verkrijgen (van de originele row dus), zonder dat ik daarvoor de physical name nodig heb ? Waarom kan ik dat niet doen met de 'typed' name ?

DataSets zijn evil.

[whoami]

Ok, ik denk dat ik het met een hele ugly work-around ga oplossen.

code:

if( myDataRow.RowState == DataRowState.Deleted )
{

     try
     {
         myDataRow.RejectChanges();
         myDataRow.Id;
     }
     finally
     {
          myDataRow.Delete();
     }

}

ugly, heh.... maar soms moet men eens pragmatisch zijn.

Waarom werkt dat gedoe met die DataRowVersion eigenlijk niet met de typed columnname.

[ Voor 12% gewijzigd door whoami op 03-05-2005 17:13 ]

[EfBe]

Op zich is het wel logisch, zij het dat ze niet hebben willen kiezen. Het probleem is dat wanneer je een row verwijdert uit een datatable, wat bedoel je dan precies: je verwijdert een row uit een set data, die je verkreeg door een select? Of verwijder je een row die ook uit de db moet worden verwijderd?

Indien het eerste, dan is de DataRowVersion raar, want de rij is weg, basta. Indien het tweede, dan is de DataRowVersion wel logisch, echter je kunt niet vertellen aan de dataset wat je bedoelt wanneer je delete aanroept

[whoami]

De row moet ook uit de DB verwijderd worden; echter, wat ik stom vind, is dat je de waarde van een veld niet uit de 'Original' Datarowversion kunt halen dmv de 'typed name'.

[D4Skunk]

whoami schreef op dinsdag 03 mei 2005 @ 22:36:
De row moet ook uit de DB verwijderd worden; echter, wat ik stom vind, is dat je de waarde van een veld niet uit de 'Original' Datarowversion kunt halen dmv de 'typed name'.

Dit is dus 'by Design'. Ik vindt het persoonlijk wel een goede suggestie voor het microsoft-team... Whoami, ga je gang

[whoami]

geen idee eik waar ik moet zijn....

[EfBe]

whoami schreef op dinsdag 03 mei 2005 @ 22:36:
De row moet ook uit de DB verwijderd worden; echter, wat ik stom vind, is dat je de waarde van een veld niet uit de 'Original' Datarowversion kunt halen dmv de 'typed name'.

Maar die rij bestaat niet meer, je hebt hem verwijderd!

Wat jij WILT, en wat er niet inzit, is dat je datatable-versioning hebt. Dus, op tijdstip T heeft table foo 5 rows, op T+1 haal je 1 weg, en op T+2 wil jij weten wat de value was van het ID veld in die verdwenen row. Wat jij _eigenlijk_ wilt, is wat de value van het ID veld was op T+0.

Original versions e.d. gaat over de row versioning, dus versioning per row. Niet per datatable.

Voordat je denkt: dat moet er toch in? Het is een erg complex probleem, want zodra je meerdere gerelateerde containers hebt met data is versioning ERG lastig. (ik heb nog hoofdpijn van het nadenken erover)

[D4Skunk]

EfBe schreef op woensdag 04 mei 2005 @ 13:12:
[...]

Maar die rij bestaat niet meer, je hebt hem verwijderd!

Wat jij WILT, en wat er niet inzit, is dat je datatable-versioning hebt. Dus, op tijdstip T heeft table foo 5 rows, op T+1 haal je 1 weg, en op T+2 wil jij weten wat de value was van het ID veld in die verdwenen row. Wat jij _eigenlijk_ wilt, is wat de value van het ID veld was op T+0.

Original versions e.d. gaat over de row versioning, dus versioning per row. Niet per datatable.

Voordat je denkt: dat moet er toch in? Het is een erg complex probleem, want zodra je meerdere gerelateerde containers hebt met data is versioning ERG lastig. (ik heb nog hoofdpijn van het nadenken erover)

Misschien een domme opmerking, maar dit zou toch net zoals bij een ordinaire datatable kunnen zijn ? Als het mogelijk is in een generieke datatable, moet toch hetzelfde mogelijk zijn voor een typed datatable ? Maw kan je eens uitleggen waarom dit problemen zou kunnen geven (liefst zonder er hoofdpijn van te krijgen )

btw @whoami : ik denk dat je voor suggesties moet zoeken naar msdn feedback

[Serpie]

whoami schreef op woensdag 04 mei 2005 @ 09:36:
geen idee eik waar ik moet zijn....

Hier: http://lab.msdn.microsoft.com/productfeedback/
Wordt ook nog best goed in de gaten gehouden door Microsoft, en je krijgt meestal wel een reactie ook.

[whoami]

D4Skunk schreef op woensdag 04 mei 2005 @ 13:52:
[...]


Misschien een domme opmerking, maar dit zou toch net zoals bij een ordinaire datatable kunnen zijn ? Als het mogelijk is in een generieke datatable, moet toch hetzelfde mogelijk zijn voor een typed datatable ? Maw kan je eens uitleggen waarom dit problemen zou kunnen geven (liefst zonder er hoofdpijn van te krijgen )

Dat denk ik ook ?
Waarom zou het zo moeilijk zijn om mbhv de typed name de gegevens van een andere datarowversion te bemachtigen ?

[EfBe]

D4Skunk schreef op woensdag 04 mei 2005 @ 13:52:
[...]
Misschien een domme opmerking, maar dit zou toch net zoals bij een ordinaire datatable kunnen zijn ? Als het mogelijk is in een generieke datatable, moet toch hetzelfde mogelijk zijn voor een typed datatable ? Maw kan je eens uitleggen waarom dit problemen zou kunnen geven (liefst zonder er hoofdpijn van te krijgen )

Een typed datatable is een class met wat accessors, verder niets, dus in feite gewoon een datatable.

Waarom table-wide versioning lastig is, zie je wanneer je meerdere, gerelateerde tables in 1 dataset stopt en FK values gaat wijzigen. Stel ik heb een customers en een orders table een datarelation. Nu ga ik van een order, die nu wijst naar het ook aanwezige CHOPS customer record, de customerid wijzigen naar BLONP. Als ik dan kijk vanaf de Customers kant, verliest CHOPS ineens een order. Is CHOPS dan ook gewijzigd?

[Yes] [No] [Asperine]

Dus Customers[index_Chops].Orders is ineens gewijzigd.Het wordt nog veel leuker bij meerdere tables

Je wilt dit gebruiken wanneer je een scherm hebt waarbij veel data wordt gewijzigd en je bij 'Cancel' weer naar de oude toestand van voor het scherm terug wilt keren.

[ Voor 13% gewijzigd door EfBe op 04-05-2005 15:03 ]

[D4Skunk]

EfBe schreef op woensdag 04 mei 2005 @ 15:00:
[...]

Een typed datatable is een class met wat accessors, verder niets, dus in feite gewoon een datatable.

Waarom table-wide versioning lastig is, zie je wanneer je meerdere, gerelateerde tables in 1 dataset stopt en FK values gaat wijzigen. Stel ik heb een customers en een orders table een datarelation. Nu ga ik van een order, die nu wijst naar het ook aanwezige CHOPS customer record, de customerid wijzigen naar BLONP. Als ik dan kijk vanaf de Customers kant, verliest CHOPS ineens een order. Is CHOPS dan ook gewijzigd?

[Yes] [No] [Asperine]

Dus Customers[index_Chops].Orders is ineens gewijzigd.Het wordt nog veel leuker bij meerdere tables

Je wilt dit gebruiken wanneer je een scherm hebt waarbij veel data wordt gewijzigd en je bij 'Cancel' weer naar de oude toestand van voor het scherm terug wilt keren.

Als je de logica doortrekt van datatables, Dan is Customers[index_chops].Orders sowieso een volatile (syntax in cpp) object, dus zie ik nog steeds niet echt het probleem ? Of bedoel je hiermee dat er bij Customers[index_chops] een changed_event moet plaatsvinden ?

[EfBe]

Als jij een aantal wijzigingen in related datatables hebt, lopen de hoeveelheid versions op, en die zijn niet in sync, want per table. Terwijl, je vanaf table A data benadert in table B, die wellicht een andere version heeft dan je wilt.