On 2-2-2018 09:29, hugo.larson@... [Firebird-Java] wrote:

>> I haven't actively at that time (I was still in high school, and my
>> 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 :)

Physicist as in physics, not a physician ;)

> > I'm inspecting what happens behind the scene in JBuilder
> DataExpress (DX).
> > 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.
>
>> Why does it even need to know that?!
>
> 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.

jOOQ isn't JPA, it is largely the opposite of that. Recently I have been
using spring-data (which uses JPA/Hibernate), but admittedly that is
mostly for high volume but very basic CRUD operations.

> I'm experimenting with BeanUtils for holding the fetched ResultSet. Any
> suggestions are welcome.

Don't try to wrap a ResultSet. You should either process the result set
immediately, or transform the result set to something (objects, maps,
etc) ASAP and then get rid of it.

I know that JDBC supports session-oriented ways of working with data,
but moving to short request/unit-of-work oriented makes a lot of things
simpler (admittedly with some extra complexity for optimistic concurrency).

>> 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 :)

;)
--
Mark Rotteveel