Subject | Re: [Firebird-Java] Additional metadata from ResultSet |
---|---|
Author | Mark Rotteveel |
Post date | 2018-02-01T14:35:16Z |
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 ;)
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.
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.
Mark
--
Mark Rotteveel
> This is a bit off topic but lets fill the this magnificent forum a bit :)I haven't actively at that time (I was still in high school, and my
>
> 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 ;)
> 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.
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.
> 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.
Mark
--
Mark Rotteveel