Hello.
Okay, I understand. We all have different setups and needs.
I am creating all the tokens and filter by type. I plan to clean up
this by adding a method named something like mayRemoveInformation() to
all the tokens. The startup merge (step 1 including metadata fetching
and issuing of tokens) is done in 6 seconds on PostgreSQL with ~90
tables, so I have not bothered optimizing. A little bit slower with
Derby.
For my setup, filtering out extra tables is not important. To speed up
junit tests, I implemented support for this in DbMerger. You just
override the includeTableName-method.
Regards,
- Tore.
On Jun 10, 2009, at 15:32 , Andrus Adamchik wrote:
Hi Tore,
We definitely looked at DbMerger, but for the implementation it was
decided to go a parallel way, essentially because most strategies
are using a much smaller subset of JDBC metadata operations for its
schema analysis, and the analysis flow needed to be flexible. E.g.
we don't care if there are extra tables in the DB, and we don't want
to fetch the columns for those. Attribute rules checking is fairly
lax (null/not null mismatch is ignored). All or nothing strategies
would abort out early if they detect a certain single object
presence/absence. Things like that, all affecting application
startup speed (not only on Oracle).
Finally we decided against including a partial update strategy for
the reasons we discussed before - production schema upgrade may
require data migration, something the strategy won't know anything
about. So essentially the conclusion was that the main strength of
DbMerger wasn't applicable for the problem at hand. Users can still
implement such strategy. With the help of DbMerger it will be
trivial indeed.
I am open to reconciling the two, just thought that it will be too
invasive on the DbMerger end. So is there optimized API for Step #1,
or does it still get all tokens with DbLoader, and then throws away
unsafe ones?
Andrus
