On 07/28/14 15:00, Jim Starkey wrote: First of all I must say that the troubles I've mentioned with prepareStatement() are vulcan-specific. I've read your arguments, they match my mind re. that issue, all the problem was due to some misunderstanding and attempt to reference JDBC in incomplete project.
In NuoDB everything is OK, it exactly matches JDBC description at Oracle site. Both have prepareStatement() call in Connection, firebird has prepare() in IAttachment, they perform same function - create prepared statement. Looks like I was right not looking at Vulcan's JDBC. > >>> 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. In version 3 we are definitely not ready to have all that fine enhancements. Or it will never get released. >>> 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. It's hard not to agree with such strong argument. >>> 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. It's hardly such argument. Most of bugs are at server side but to demonstrate them people send Delphi applications, not Java. >>> 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. Looking at NuoDB interface it seems that changing current (FB3) provider interface to JDBC is not too big problem. I hope that adding some additional, non-JDBC calls to API os not too big violation of it? They are required first of all to emulate ISC API. And we can even keep it a kind of Delphi-friendly with minimum set of additional calls :) But that's not what only I decide. An argument that for a person who used to work with ISC API for a long time change to current fb3 API is simpler than to JDBC one remains present. And an idea If we decide that having JDBC as a main firebird interface is a good idea as a possible solution not (almost not) delaying FB3 release may be used the following. Logically what FB3 interface does is very close to JDBC. We can rename interfaces in Provider.h to make them match the close-most JDBC interface (i.e. IAttachment becomes Connection, IStatement => PreparedStatement, etc.) which will help build in next version an interface which meets JDBC requirements at the same time remaining compatible with what we have now. ------------------------------------------------------------------------------ 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
