> Totally agreed....I guess the question is though if that is going
to part of what we
> today call Dialect or something else (If i follow Steve's comments right)
The vast majority of databases out there have more or less decent JDBC
drivers.
Actually, that ain't true when it comes to metadata about their metadata (remembering
my fights with Oracle, MySQL, db2
and sqlserver when doing reverse engineering) - but ignoring that :)
So forcing every single Dialect to reproduce information that
is already correctly available to us because of a few *known* slackers
seems silly.
Completely agree - there should be a way to fallback to the automatic metadata.
Why can't the majority of Dialect's say "you know
what...
you can already get this information via the driver's DatabaseMataData;
go look there"? Thats all I'm saying.
So because Sybase has crappy JDBC drivers (ok thats a tad harsh, but
making a point...) we need to penalize every Dialect developer into
duplicating this information?
For something like this, here is what I would propose...
1)
public interface ObjectNameRenderer {
public String render(OjectName objectName);
}
2)
Dialect {
...
ObjectNameRenderer getObjectNameRenderer() {
return TrustMetaDataObjectNameRenderer.INSTANCE;
}
}
And also allow one to be plugged in via "config", which would take
precedence if present.
There is actually another reason why users would like to not delegate to
the JDBC drivers metadata - if a driver changes behavior or fixes bugs (and yes, they
sometimes do)
Hibernate's reliance on database metadata might cause change in behavior of the
Dialect even though
the only change were the database driver.
Will that be a problem ? I don't know for sure; but I do recall a few
"incidents" with drivers changing behaviors
that could manifest it self in arcane ways if the Dialect were fully databasemetadata
driven.
Anyway, with the above approach its doable :)
/max