2 p.m.
Max,
Could you please review this small code snippet and answer -
Do I think/move in a right direction?
Vitali
2:10 p.m.
Is this for the code completion work ?
Then I don't really understand why JDBCReader needs altering ?
Why not read it directly via CachedMetaDataDialect and use a custom database collector
to get it all indexed as you need for code completion ?
Maybe i'm missing something ?
/max
Max,
Could you please review this small code snippet and answer -
Do I think/move in a right direction?
Vitali
2:49 p.m.
I am expecting such readings should be in one place and JDBCReader seems to
be a right place.
Also I try to propose solution for common case where database collector is
default database collector.
Ok, clear - the custom database collector - you told about it - but I did
not see solution outside JDBCReader.
So, at least, my code for JDBCReader.readDatabaseTables suitable manner to
get tables and the same for columns. OK.
-----Original Message-----
From: Max Rydahl Andersen [mailto:max.andersen@redhat.com]
Sent: Thursday, March 27, 2008 9:11 PM
To: Vitali Yemialyanchyk
Cc: jbosstools-dev(a)lists.jboss.org
Subject: Re: JDBCReader question
Is this for the code completion work ?
Then I don't really understand why JDBCReader needs altering ?
Why not read it directly via CachedMetaDataDialect and use a custom database
collector
to get it all indexed as you need for code completion ?
Maybe i'm missing something ?
/max
Max,
Could you please review this small code snippet and answer -
Do I think/move in a right direction?
Vitali
2:47 a.m.
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
10:17 a.m.
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.
In situation with JDBCReader - I put some remarks into the code - the
difficult of situation here -
1) Do we really need configurable solution (very configurable) to get
tables/columns?
And
2) Performance problem - I check it (create unit test) - and see what
processing of columns is a most time consuming thing;
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.
Configurable solution and JDBCReader change - requires SchemaSelection new (
String matchColumn; ) member.
Also configurable solution should solve the performance problem - in this
case we should process columns only in the case when configuration requires
this - 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.
In the case when we just merge JDBCTablesColumnsReader & JDBCReader into one
- bulk-reading code should not be changed.
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
10:42 a.m.
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
11:04 a.m.
-----Original Message-----
From: Max Rydahl Andersen [mailto:max.andersen@redhat.com]
Sent: Monday, March 31, 2008 6:43 PM
To: Vitali Yemialyanchyk
Cc: jbosstools-dev(a)lists.jboss.org
Subject: 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 ?
I attach the code of JDBCTablesColumnsReader.
> 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 ?
I 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) ?
Ok. Your answer just state what it was not a right solution.
> 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.
?
You see - JDBCTablesColumnsReader & JDBCReader could be merged without
changes in JDBCReader bulk-reading code.
/max
Vitali
6091
days inactive
6095
days old
jbosstools-dev@lists.jboss.org
6 comments
2 participants
participants (2)
-
Max Rydahl Andersen -
Vitali Yemialyanchyk