Hi Knut,
Thanks for your answer. May I suggest that this be added to the documentation of generated columns?
I think support for virtual columns, as they're indeed called in some other DBs, would really be nice though. For instance, Java Enums fit nicely as a UDT, but indexing on them (or even simple comparisons) would require a separate column with the ordinal integer value or the name string; in the latter case, the space requirement is rather superfluous relatively to that of the enum value itself. It seems to me this could be used as a partial solution at least to expression-based indexes (Derby-455), by requiring indexes on simple columns which may be virtual, or implementing the index by defining a hidden virtual column, or something of the kind. Do you know if there's any Derby improvement suggestion in that direction? (I havent'found any).
Uriah Eisenstein

On Thu, Sep 2, 2010 at 10:46 PM, Knut Anders Hatlen <knut.hatlen@oracle.com> wrote:
Uriah Eisenstein <uriaheisenstein@gmail.com> writes:

> Hi,
> I searched around for the actual implementation of column "generated
> always as " but couldn't find anything, except maybe by
> digging into Derby source code which I don't want to... I want to
> know whether a generated column is a "real" column existing within
> the DB storage, and is updated whenever the columns it depends on are
> updated - or is it a "virtual" column which is recalculated whenever
> it is read. I don't have a specific need for it right now, but such
> columns can be useful for indexing and such, e.g. of case-insensitive
> strings or of UDTs, so I think it is useful to know whether the price
> is mainly in space requirements (if they're "real") or just in
> performance when reading.

Hi Uriah,

The generated columns are physical columns stored in the tables, and
they are updated whenever a column they reference changes. You can also
create indexes on the generated columns.

Knut Anders