Re: [JDBC] TypeInfoCache

From: Daniel Migowski <dmigowski(at)ikoffice.de>
Date: Tue Jan 08 2008 - 05:30:03 EST

Hello Gregory,

Gregory Stark schrieb:
> "Daniel Migowski" <dmigowski@ikoffice.de> writes:
>
>
>> I can understand your concerns, if you are used to applications that store
>> everything in text-fields on the database. But a problem is only if you have
>> such an applicatoin, and forgets about its database fields and uses the
>> metadata to remember what its fields have been, now notices the data is in
>> LONGVARCHARs, and uses the stream-methods.
>>
>
> I think that's quite likely though if you build an application and then later
> throw some generic tool at it such as a reporting tool, or a schema design
> tool, or a migration tool or something like that.
>

Is reasonable, yes.
> But I wouldn't be too worried about a slowdown. I would be more worried about
> having said tool see LONGVARCHAR and throw its hands in the air and refuse to
> include it in your reports. Or insist on migrating it to or from MEMO fields
> instead of plain strings.
>

What would be the problem with this? text fields ARE memo fields. Use varchar(n) if you want length constrained fields :).
> Perhaps this is all just FUD though.

In fact LONGVARCHAR is made easy in JDBC, since it is required to be accessible by the same functions as VARCHAR.
> I haven't seen such a case myself. I was
> under the impression such cases had been previously posted on list but if
> you've searched and not found anything then perhaps I'm thinking of some other
> scenario.
>

In fact I searched for LONGVARCHAR on the list, and everything I got are complaints that it is not supported in the metadata (in about 4 threads). Of course we could not get complaints for the reversed case, in which LONGVARCHAR itself was a problem, yet.

With best regards,
Daniel Migowski

---------------------------(end of broadcast)---------------------------

TIP 6: explain analyze is your friend Received on Tue Jan 8 05:32:13 2008