The point 2 was supposed to be a small change.I said to myself that I would be kind to make the change. Call me Mr Nice Guy... :)
Well... There are a LOT of changes required: 1. All control needs to go back to DataContext (I noticed this problem a long time ago, with the IManagedTable interface, whose purpose was just a workaround). 2. The right way to process entities, it NOT AT ALL to process all INSERTs, then, UPDATEs, then DELETEs successfully. No, all registered entites must be processed as a single list (this will be fun), as they come. 3. Since entities are in a single list, they can also be "ignored": for example, adding an entity for insert, then registering it for delete will just mark it as "to be ignored" in list... So, this is a bit more tricky than I expected to get things done correctly. But necessary anyway. Be patient! On Mon, Sep 29, 2008 at 15:12, Julio César Carrascal Urquijo < [EMAIL PROTECTED]> wrote: > > Hi Pascal > > On Sep 28, 4:36 pm, "Pascal Craponne" <[EMAIL PROTECTED]> wrote: > > 1. This is an important point, and I don't like much the idea of giving > > control to the vendor (it would give to much responsibility on the > > vendor).Ideally, > > the Upsert would be able to support the following variants: > > - Single query insert > > - Double query insert, generated columns values being loaded after the > > insert statement (Ingres requirements) > > - Double query insert, generated columns values being loaded before the > > insert statement (Firebird) > > So maybe we could find a compromise like: > > - vendor declares its requirements (one in the three above, or something > > more extensible) > > - core executes queries, depending on the vendor's requirements. > > > > This needs to be refined, before implementation, and I'd like to get > other > > contributors' opinion. > > That would work, for Firebird at least. Thanks > > > > 2. Yes, I understand, and this could be easily done. Anyway, we must keep > in > > mind that this is just a workaround, until DbLinq fully manages entity > sets. > > I understand. But I want to stress that this is a blocker for most > uses of DbLinq. A simple CRUD application would require specific > ordering of statements if the database has foreing keys. > > Cheers. > > > > -- Pascal. jabber/gtalk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
