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. 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. On Sun, Sep 28, 2008 at 21:53, Julio César Carrascal Urquijo < [EMAIL PROTECTED]> wrote: > > Hi Pascal > > On Sep 28, 1:40 am, "Pascal Craponne" <[EMAIL PROTECTED]> wrote: > > Hi Julio César, > > that's good news anyway :) The vendor model was designed to be easily > > extensible, and apparently we succeeded. > > Regarding your questions: > > 1. Initially, all queries were working in a single statement, but we had > to > > change this behavior to double statement for Ingres. I still fear that we > > have problems on some vendors where executing two requests may be > different > > that executing a double one. So it is planned to support single and > double > > requests. Can you make the insert statements fit in one single request? > > Mmm, no. The Firebird ADO.NET provider doesn't support multiple > queries with FbCommand. I've read the way is done in Ingress (getting > the current value of the sequence after the insert) but I think that > isn't safe on Firebird with multiple users because another ID might > have been generated outside the transaction. > > Sadly QueryRunner.Upsert() cant be overwritten. Is there any other way > to override the order in which insert statements are executed? Maybe > defining BeforeInsert/AfterInsert callbacks could fix the issue with > different vendors. > > > > 2. Dependencies are not supported yet, so this there's probably nothing > to > > do now (except implementing cascading in DbLinq core). > > I don't mean dependencies but a way to specify the order in which > statements are executed. > > Obviously I have to delete the Order Details before the Order. The > problem is that because the Order table is used before *in an > unrelated query* it's delete is issued before the Order Details. > > I think statements should at least execute in the order they are > registered in the source code: > > db.OrderDetails.DeleteOnSubmit(od); // Delete OrderDetails first. > db.Orders.DeleteOnSubmit(order); // Then the order. > db.SubmitChanges(); > > > > Let me know if you want to be added to project's contributors, so you can > > commit firebird support by yourself. > > Maybe latter when I have something more useful. > > > > Just one question: does you implementation support schema extraction (so > it > > can work with DbMetal)? > > Partially, there's some support already but for the time been I just > copied the Northwind.cs from DbLinq.MySql.Example and manually changed > some lines to test it. > > Thanks > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
