:( Guess I'll have to move to the city.
Anyway, yes: it is kind of hard.
Think about it:
You have a huge table, you add a column, which updates all rows in
column to have a value.
If you have no default and the column is NULL(able), then the update is
to all NULL values.
If you have a default value, then the update is to the specified
DEFAULT.
(the remaining case is illegal: add column not null with no default)
If you do not implement sophisticated, versioned, row-wise incrementally
update-able structural meta data, then the update has occurred fully and
literally (i.e. on disk and/or in memory)
Say you have not implemented the features in the previous paragraph.
Then you decide to roll back. Arg. Huge amount of wasted work.
Say you have implemented the features for versioned, row-wise
incrementally update-able structural meta data (i.e. the system does not
need to make any actual physical row structure changes until it
encounters rows whose meta data version stamps are older than the global
stamp for the owning table's current meta data structure).
Example:
Table(current meta data version index)
has list of (meta data descriptor), list of (row (data, meta data
version number))
Then you can perform transactions that intermingle changes to a table's
structure with updates to its row data, and only rows touched since a
change to table structure need to really be physically modified, in a
structural, rather than content sense)
But now you must implement not only row data versions, but also row
structure meta data versions in your rollback structures. Arg.
Now add indexes (same thing as rows...need to record structural meta
data version), check constraints (same) and foreign keys (same) into
the picture.
Now I'm sure there's lots of things I've missed...
... and the last they saw of Campbell, he was screaming, pulling his
hair out and disappearing over the horizon at high speed.
Get the picture?
One day, in the dim, distant future, this issue may be addressed, but
certainly not before other far more pressing issues have been addressed,
such a:
a) better than read committed isolation
b) decent query optimization under complex joins and predicates
c) efficient, rather than since-the-beginning-of-time checkpoints and
recovery for cached/text tables
Although the ability to perform structural modifications in a
transactional manner is certainly convenient and highly desirable,
I've always felt that if one's database (or application/business) object
definitions are changing so rapidly that one dreams of DBMS/IDE that
support all mutations with ease and in a transactional setting, then its
pretty likely that either:
1.) there was not enough time/money/manpower up front on the project
2.) Development is proceeding too literally and is reacting
incrementally at too fine a granularity to changing requirements.
(i.e. without the required effort/expertize applied to normalizing for
flexibility and refining appropriate domain generalizations)
Given the code I have to deal with in my daily legacy application
support role, I'd say a mediocre tool in the hands of a great team
will almost always produce better results than a great tool in the hands
of a crappy team or used in a hostile or anti-productive development
environment (under dark-side management, in a sweat-shop or politically
challenged organization, etc.)
On Sun, 2005-03-13 at 04:25, Rainer PrÃbster wrote:
> Hello Lorna,
>
> you have lost your farm: Postgresql does support this! :-)
> I.e. with Postgresql you can manipulate ddl within every transaction and roll
> back the whole transaction if an error occurs.
> This is a truely professional feature. Even more: If you have to manipulate
> your ddl often (in productive systems), this feature is fundamental!
> I did know that Oracle (8.x) did not support this and I was really
> surprprised that time ... what a shame for such a big and expensive system!
> As I don't know how hard it is to implement this, I won't suggest ... ;-)
>
> Cheers,
> Rainer
>
>
>
> Lorna Burnet wrote:
>
> >It happens because in hsqlsb, currently, data definition language execution
> >is not "transactional"
> >
> >That is, you cannot roll back table creation, etc.
> >
> >So, if you issue ddl in the middle of a transaction, this is equivalent to
> >an implicit commit.
> >
> >The same is true of many DBMS, including Oracle, MS SQL Server, etc. I
> >can't say off the top of my head, but I'd bet the farm that the same applies
> >to Postgresql, MySQL, etc. In fact, I think you'd have to really search
> >carefully to find the small handfull of systems that actually support ddl
> >operations as undoable transaction items.
> >
> >
> >Where HSQLDB really needs work regarding ddl is not to support undoable
> >itms, but rather to support cross-session ddl locks. For instance, try
> >updating a table inside a transaction in one session, then drop the table
> >inside another session, and then roll back the first session. Likely,
> >you'll get a "table not found" exception in the first transaction, whereas
> >IMO it would probably be better to raise an exception in the second session,
> >stating that one cannot drop or alter the table, because it is in use by
> >another session.
> >----- Original Message -----
> >From: Irum Godil <[EMAIL PROTECTED]>
> >Date: Friday, March 11, 2005 11:06 pm
> >Subject: [Hsqldb-developers] Transaction Commit
> >
> >
> >
> >>Hi,
> >>I am going through the Hsql Database code, and I noticed that in
> >>the class DatabaseCommandInterpreter the call to Session.commit is
> >>happening in a few places. One such example is in method:
> >>
> >>private void processCreateTable(int type) throws HsqlException {...}
> >>
> >>I see that if I have created a table, done some transactions on the
> >>table, and now create a new table; then all the transactions made
> >>on the first table are committed by call to function:
> >>
> >>Session.Commit( )
> >>
> >>I do not understand why is this being done. If I have turned
> >>AutoCommit to false, then I do not want any commits to happen until
> >>I explicitly call commit( ) right? So, if some transactions are
> >>being committed, then is not that wrong. How is atomicity of
> >>transactions preserved in such a case?
> >>
> >>Thanks.
> >>
> >>
> >>
> >>
> >>
> >>---------------------------------
> >>Do you Yahoo!?
> >>Yahoo! Small Business - Try our new resources site!
> >>
> >>
> >
> >
> >
> >-------------------------------------------------------
> >SF email is sponsored by - The IT Product Guide
> >Read honest & candid reviews on hundreds of IT Products from real users.
> >Discover which products truly live up to the hype. Start reading now.
> >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >_______________________________________________
> >hsqldb-developers mailing list
> >hsqldb-developers@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
> >
> >
> >
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> hsqldb-developers mailing list
> hsqldb-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
hsqldb-developers mailing list
hsqldb-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
