> On Jul 28, 2014, at 6:23 AM, Alex Peshkoff <peshk...@mail.ru> wrote: > >> On 07/25/14 18:43, Jim Starkey wrote: >> If an interface is incompatible, existing applications have to be recoded. >> If they need to be recoded, there isn't any real purpose to retaining an >> interface "style." > > For existing applications we support legacy ISC interface. Certainly, > when new features (like schema) will be added, they will be accessible > only from new one. > >> I don't understand the difference between creating a statement in prepared >> state and prepareStatement. Could you explain? > > Presence of "prepareStatement" in API suggests a user to prepare same > statement instance multiple times.
Alex, I'm terribly afraid that you misunderstood prepareStatement. It is used for one of two reasons. First, so the statement can be reused without subsequent preparation. This is what you got backwards. It doesn't suggest that a statement has to be prepared multiple times. It SAYS specifically that it doesn't. The second usage to to set up the mechanism to accept input parameters. It is not unreasonable to expect users to read the documentation. > >> And explain why Connection::prepareStatement is bad. > > I see 2 ways how prepareStatement may be implemented. > > First - execution of it can be enabled only once (like setCursorName() > in ISC API). In that case we just have useless API call - all of it's > functionality might be moved to statement creation. RTFM. > > Second - multiple execution of prepareStatement for same statement > object may be enabled. In that case I see a need in a lot of related > activity in client program (like changing parameters formats) that > should be done in sync. Changing some data structures instead of > creating a new one is a potential source of errors. Also a problem > exists what to do with cursor name set for a statement. According to SQL > CLI it should be cleaned, but I'm sure not all users will like that > approach - it's not intuitively logical that re-preparing statement > drops cursor name from it. Your parameter argument is without substance. There is nothing difficult or bug prone in using or implementing it. You are aware, I hope, that there is no requirement that the parameter type need match anything. > >> Fetching values from a result set does require a virtual function call. >> That's may 10 nanoseconds on the client side, maybe. On the other hand, it >> completely isolates the client from whatever the database engine generated >> as a type. > > Is it good in all cases? Data types (specially numeric data types) is > rather conservative thing, they usually match in engine and language. > Hiding the fact that engine in some particular case is using for example > 16-bit value with int in API can become a source of errors instead good > service. It is better to give a runtime error for integer overflow than to hope a compiler flags it. But it is far, far better to support flexible numeric types without declared precision. NuoDB does this -- a number is a number is a number. Put a number in, get the same number out. It accurate reflects the intuitive idea that a number reflects a numeric quantity rather than a specific fixed length bit pattern. But it doesn't work with preformatted fix length record structures... Same argument applies for unbounded string types. Punch cards are long gone and unlikely to return. Get over it. > >> Remember that the original interface was designed for use with a >> preprocessor that allowed free references to database values within a >> database block. They was a very good idea in its day, but preprocessors >> have gone by the way side. > > Yes, but on the other hand accessing data buffer today does not > necessary require preprocessor. A set of templates (probably combined > with macros) in C++ provide enough service for one who wants to use API > without any additional layer over it. Alex, you are probably aware that I have some experience here that you lack. Not having to setup, populate, and reference fixed length buffers is very liberating. Do remember that I invented this stuff, so when I say there are many better ways to do this, I do have some insight into the problem. > >> Coersing data into predeclared structures no longer makes sense, > > Why? Imagine a visual design component associated with SQL statement. > User opens select statement, probably changes data types of returned > values, component stores them and build interface (IMessageMetadata in > FB3 case) which is passed to openCursor() at runtime. fetchNext() > returns buffers in exactly that form that is needed for component, and > how does it parse them later is that component deal. > I.e. yes, we do not have 'struct isc_371' with a set of fields in source > code, but structure of data buffer may be predeclared in other way. > >> and managing dynamically structured buffers is a royal pain in the butt. > > Here I do agree. > >> My guess is that 80+% of all database client access is through Java. > > May be, but most of bug reports we get are from delphi clients. Isn't that an argument against Delphi and the Delphi interface? Maybe making it simpler rather more complex is the solution. > >> Moving the database engine, API, and protocol closer to JDBC would go a long >> way to eliminating unnecessary overhead. >> >> And I don't understand what you mean about JDBC being "too high level." >> Could you explain? > > I've meant first of all use of function calls to access value of any > single field returned by DB engine. Alex, this a how all application work -- use a call to get a value. The difference is that in JDBC the functions already exist but in Firebird, you have to write them. I suggest you actually try alternative interfaces before you reject them out of hand. The world of OO programming (which didn't exist when I designed the existing interface) is really quite enabling. > > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
