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."
I don't understand the difference between creating a statement in prepared state and prepareStatement. Could you explain? And explain why Connection::prepareStatement is bad. An interface does need a way to set a local character set when it can't be determined from the system locale. Internally, however, everything is utf8. Phasing out character sets in the database system proper would be a very good thing. 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. 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. Coersing data into predeclared structures no longer makes sense, and managing dynamically structured buffers is a royal pain in the butt. My guess is that 80+% of all database client access is through 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 done a huge amount of application level database code using JDBC (the Netfrastructure / NuoDB engines are natively JDBC, so a Java JDBC call went straight to the C++ implementation method, reducing the Java overhead to a half dozen machine instructions. I found that JDBC very convenient for both application and tool work. > On Jul 25, 2014, at 9:38 AM, Alex Peshkoff <peshk...@mail.ru> wrote: > >> On 07/25/14 06:11, Jim Starkey wrote: >> Why not just use the C++ binding of JDBC that I wrote for Vulcan? > > Main reason is that I wanted to have something more or less similar to > existing ISC API. Certainly removing such things as SQLDA and adding > interfaces-style replacement. > > What about JDBC in Vulcan - sorry, I did not take a look at it. I've > quickly reviewed it today and must say that in some aspects I do not > find it appropriate for FB3. > > JDBC contains standard but bad prepareStatement(). We have used better > approach when statement is created in prepared state by an attachment > according to it's SQL text. It's much more clear. > > Also JDBC in Vulcan is missing charset information (certainly, one can > be added). > > Accessing individual columns in JDBC is definitely overhead (may be I've > missed something in it but for what I see to get any single value from > result set I need virtual function call). That's sooner of all OK when > using API to write final applications. But low-level database API is > typically used to built something else (like Delphi components) based on > it. And for this purpose fb3 is definitely better cause it works with > message buffer directly (more or less like GPRE-compiled programs). > Access to individual field is based on offset in message buffer which is > certainly not so beautiful as virtual function returning "Value*" by > column name but makes much more sense for a component that just caches > messages in own memory and later accesses them itself well knowing > message structure. And yes - for C++ we have wrappers around the message > that enable access to it similar to JDBC, but without relatively slow > virtual calls. > > Once more sorry if I've missed something in Vulcan's JDBC, but from what > I've found I do not want to use it - first of all it's too high-level, > we do not need all it's power for low-level DB API. > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
