|
From: Isabelle M. <isa...@me...> - 2003-05-23 18:41:32
|
Hi everyone, Having finally managed to get the livetest cases to compile (thanks to Rod's laser eyes), I've discovered a fundamental problem in SqlOperation.compileInternal(). When using key generation, part of the binding is deferred to the KeyBinder callback interface, and so SqlUpdate.compile() fails because one less parameter has been bound than declared. So somehow compile must be able to sense that a key generator is being used and then accept num params - 1. I can think of a number of solutions, none of which I particularly like : (1) a useGenerator property which must be set/unset as necessary. The bad thing about this one is that JIT compilation won't work. (2) introduce a new ctor with a boolean arg, usesKeyGenerator; but then this screws up reuse of the same SqlUpdate. (3) declare a usesKeyGenerator method(), which returns false in SqlUpdate, and create a SqlInsert that derives from SqlUpdate and implements the method to return true. In SqlUpdate's compileInternal, call usesKeyGenerator and act accordingly. Of the bunch, I think (3) is the least evil. Does everyone agree? Or does anyone have a bright idea of how to solve this differently? Isabelle -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |