[jbosstools-dev] RE: JDBCReader question
Vitali Yemialyanchyk
vyemialyanchyk at exadel.com
Mon Mar 31 12:04:51 EDT 2008
-----Original Message-----
From: Max Rydahl Andersen [mailto:max.andersen at redhat.com]
Sent: Monday, March 31, 2008 6:43 PM
To: Vitali Yemialyanchyk
Cc: jbosstools-dev at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JDBCTablesColumnsReader.java
Type: application/octet-stream
Size: 5334 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20080331/13d79435/attachment.obj
More information about the jbosstools-dev
mailing list