[jbosstools-dev] Re: JDBCReader question
I have created JDBCTablesColumnsReader - it not be difficult to
incorporate
it back into JDBCReader.
But now I do not sure should we place it back. I prefer to discuss it late -
when I prepare all test cases and unit tests.
ok - so you want to show the code later ?
2) Performance problem - I check it (create unit test) - and see
what
processing of columns is a most time consuming thing;
Did you check it or are you saying you are going to check it ?
When I create JDBCTablesColumnsReader - my answer to first question
was:
We do not need such solution and simple case - JDBCTablesColumnsReader -
solve all situations which code completion requires.
I'm not sure what you mean here ?
Configurable solution and JDBCReader change - requires
SchemaSelection new (
String matchColumn; ) member.
that makes no sense. Schema Selection is for reveng.xml where selecting individual columns
is not usefull.
I also don't understand how that can be usefull in code completion ? If you know which
table
the code completion is for why not read all columns for that table immediatly instead of a
specific column (and
then of course cache it via CachedMetaDataDialect) ?
Also configurable solution should solve the performance problem - in
this
case we should process columns only in the case when configuration requires
this
yes.
so latter we can get situation when we have some tables which
columns
has not been processed - so we should handle the situation - so bulk-reading
code should be changed.
I don't understand this ?
In the case when we just merge JDBCTablesColumnsReader &
JDBCReader into one
- bulk-reading code should not be changed.
?
/max
Vitali
-----Original Message-----
From: Max Rydahl Andersen [mailto:max.andersen@redhat.com]
Sent: Monday, March 31, 2008 10:48 AM
To: Vitali Yemialyanchyk
Cc: jbosstools-dev(a)lists.jboss.org
Subject: Re: JDBCReader question
On Thu, 27 Mar 2008 20:49:22 +0100, Vitali Yemialyanchyk
<vyemialyanchyk(a)exadel.com> wrote:
> I am expecting such readings should be in one place and JDBCReader seems
to
> be a right place.
Your are right - what I did not understand why existing bulk-reading code
should be changed ?
/max