> > One example would be to store the TID (transaction ID) of the record

when it

> > was inserted and maintain it permanently in order to have persistent
> > bookmarks without having to hold up garbage collection. This does

increase

> > the size of the record stored on disk, increasing the I/O to deal with

the

> > record, but I think there are some ways to make it up.
>
> This I do not agree with. I would like to have the information
> available in a trigger, but I would like to have the choice to include
> it in my record structure. I want the tool, not be forced to use that
> tool.

I agree that something like this should be optional. Perhaps it could be a
global database parameter like page size that would govern the behavior of
the database. They could be called short keys or long keys. Or, perhaps,
persistent keys.

Too bad you didn't attend the conference session directed by Jim Starkey,
Ann Harrison and Charlie Caro that covered this very challenge. We discussed
at length how to implement such a feature. This capability is needed for
InterBase to effectively grow. Unfortunately we didn't reach a conclusion as
a whole as to how it should be done.

Keep in mind, I believe the TID is only 4 bytes and it would (hopefully) be
possible to flag the record with a bit such that it would only be necessary
to store the original TID when the record had actually been touched. This
way, it would only be an increase in disk space once the record had actually
been updated. I really don't think that 4 bytes max per record is all that
significant...

What I wonder about the TID is if they ever use the negative range of
numbers (assuming it is a longint and not a longword). If it is an integer
and the negative range is open, what could be done is store the negative of
the original TID when the record is updated and then place after it the TID
of the current transaction when updated. This gives us the benefit of the
original TID being self-flagging. Future updates would simply maintain the
original TID as its negative and replace the former current TID with the new
one. This would have the benefit if making the BDR (back difference record)
only carry the weight of the original TID once.

It's not adding a tool that you have to use. It's firming up the foundation
of InterBase so that it has some growing room in areas that are absolutely
critical for its long-term success. IMHO

I agree that these "growth" areas should be targeted as pluggable modules so
that the compact and embeddable nature of InterBase is preserved. But, the
foundation must be expanded for this to take place and that is going to cost
just a little bit for a huge return...

For crying out loud, someone who uses IB at an Enterprise level like
yourself, would be the last person I would suspect disagreement from when
suggesting practical solutions to things that, although I'm sure you enjoyed
inventing alternatives on your own, would perhaps spared much time and
nerves to spend with your family instead. Not to mention your company's
budget.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com