Subject | Re: [Firebird-Java] Additional metadata from ResultSet |
---|---|
Author | |
Post date | 2018-02-02T08:29:13Z |
On 1-2-2018 04:38, hugo.larson@... [Firebird-Java] wrote:
initial (later derailed) path was to become a physicist), but I'm quite
aware of some of the historic baggage of JDBC ;)
Well good for the world of Java and Firebird that you didn't become just another doctor :)
I haven't actively at that time (I was still in high school, and my> This is a bit off topic but lets fill the this magnificent forum a bit :)
>
> Do anyone here remember the early days of JDBC?
initial (later derailed) path was to become a physicist), but I'm quite
aware of some of the historic baggage of JDBC ;)
Well good for the world of Java and Firebird that you didn't become just another doctor :)
> I'm inspecting what happens behind the scene in JBuilder DataExpress (DX).Why does it even need to know that?!
> DX parses the SQL query and try to find what tables are queried. It
> often fail because the parser don't even recognize JOIN and other of the
> "modern" SQL syntax. This thing is really old.
> First I started to fix the parser and then I inspected the
> FireBirdResultMetaData and found that the tablename is conveniently
> there already. So instead of parsing the SQL to find the tablename it
> can be set directly from the metadata.
> Very good I thought. Now I can skip the DX parser altogether but in the
> back head I wonder why Borland didn't do that from the start. I cannot
> in the source code find any other reason to parse the SQL except to map
> the tablename but maybe I'm missing something because the code is a mess.
Tablename is used to create DX Column objects to be used later for inserts and updates on fetched DataSet.
In any case, I know I have said this before, but you might want to look
at a way of removing your reliance on DataExpress.
Yeah you are right but I just haven't figured out what to replace it with. You mentioned JOOQ before. I'm not a fan of JPA and creating Entity classes for every query. JPA implementations feels so old, bloated and overkill.
I'm experimenting with BeanUtils for holding the fetched ResultSet. Any suggestions are welcome.
> Could it be that early JDBC didn't have tablename ingetTableName() is defined in java.sql.ResultSetMetaData, which has been
> resultsetmetadadata? I cannot find the old JDBC specifications.
present since JDBC 1 (not 100% sure if JDBC 1 was in Java 1.0 or 1.1),
and given there is no @since annotation in the javadoc, we can infer
that getTableName() has been present since the start. Later additions
are explicitly annotated with the Java version of introduction:
Java 1.2 = JDBC 2.1
Java 1.4 = JDBC 3.0 (including JDBC 2.0 extension API aka javax.sql.*,
which was initially a separate jar)
Java 6 = JDBC 4.0
Java 7 = JDBC 4.1
Java 8 = JDBC 4.2
Java 9 = JDBC 4.3
The problem was probably one of availability, a lot of things in JDBC
are on a 'best effort' or 'lowest common denominator' basis, so if a
driver doesn't have the information, it can (and likely will) just
return empty string.
Good point. DX was supposed to be a generic library for all JDBC drivers (go figure) and probably getTableName was not reliable with other JDBC drivers.
Thanks for the reply.
I promise this is the last time I mention JBuilder and DataExpress anywhere on the Internet :)
//Hugo
Mark
--
Mark Rotteveel