[hibernate-dev] Table and quoted names
Max Rydahl Andersen
max.andersen at redhat.com
Mon Oct 4 01:39:25 EDT 2010
>> 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
More information about the hibernate-dev
mailing list