I just committed a new version of DataContext where all lists (insert, update and delete) are handled in a unified entity tracker. Tests show that apparently things still work, but this is not a 100% certainty. Please let me know if you find some regressions that slipped through the net. Regarding our point 2: all requests (insert, delete) are handled in correct order.
On Mon, Sep 29, 2008 at 22:20, Pascal Craponne <[EMAIL PROTECTED]> wrote: > 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] > > -- 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 -~----------~----~----~----~------~----~------~--~---
