[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