Menu
▾
▴
firebird-devel
|
From: Jim S. <ja...@ne...> - 2004-06-10 15:08:27
|
I've been exploring ways to make uncommited DDL operations work with SQL
integrated into the engine. I think I have a solution that works. The
basic idea is the transaction object maintains it own list of
transation-specific relation objects. SQL language processing currently
calls in CStatement::findRelation to location relation objects.
CStatement::findRelation used to call Database::findRelation. Now it
calls a new Transaction::findRelation. I thought it rather classical,
all in all, so rather than describe it, I'm reproducing it below,
comments and all:
Relation* Transaction::findRelation(tdbb *tdbb, const char*
relationName)
{
Database *database = tra_attachment->att_database;
Relation *relation = database->findRelation(tdbb, relationName);
if (relation)
return relation;
for (relation = pendingRelations; relation; relation =
relation->rel_next)
if (relation->rel_name == relationName)
return relation;
Connect connection = getConnection();
PStatement statement = connection->prepareStatement(
"select rdb$relation_name from rdb$relations where
rdb$relation_name=?");
statement->setString(1, relationName);
RSet resultSet = statement->executeQuery();
if (resultSet->next())
{
relation = FB_NEW(*database->dbb_permanent) Relation
(database, -1);
relation->rel_name = relationName;
relation->fetchFields(connection);
addPendingRelation (relation);
}
return relation;
}
The lifetime of the relation objects created by Transaction is the life
of the transaction. Temporary relation objects currently contain
minimal data, but this can be expanded as required. Relation objects
are current just deleted. Sometime we'll probably have to cut over to
reference counting.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
|
|
From: Jim S. <ja...@ne...> - 2004-06-10 15:24:34
|
Jim Starkey wrote: > I'm reproducing it below, comments and all: [butchered code follows] Sigh, it didn't look like that when I sent id. Pox on mail clients! -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
|
From: Alex P. <pe...@in...> - 2004-06-10 15:56:21
|
Jim Starkey wrote:
> I've been exploring ways to make uncommited DDL operations work with
> SQL integrated into the engine. I think I have a solution that
> works. The basic idea is the transaction object maintains it own list
> of transation-specific relation objects. SQL language processing
> currently calls in CStatement::findRelation to location relation
> objects. CStatement::findRelation used to call
> Database::findRelation. Now it calls a new
> Transaction::findRelation. I thought it rather classical, all in all,
> so rather than describe it, I'm reproducing it below, comments and all:
>
> Relation* Transaction::findRelation(tdbb *tdbb, const char*
> relationName)
> {
> Database *database = tra_attachment->att_database;
> Relation *relation = database->findRelation(tdbb, relationName);
> if (relation)
And what about 'DROP TABLE/VIEW'? Dropped relation will be found in the
transaction, which issued this command. May be 2 lists of pending
relations - new and dropped? And before return check, has not given
relation got in the second list. Certainly, it will be necessary to add
relations to this list from drop_relation() code.
> return relation;
> for (relation = pendingRelations; relation; relation =
> relation->rel_next)
> if (relation->rel_name == relationName)
> return relation;
> Connect connection = getConnection();
> PStatement statement = connection->prepareStatement(
> "select rdb$relation_name from rdb$relations where
> rdb$relation_name=?");
> statement->setString(1, relationName);
> RSet resultSet = statement->executeQuery();
> if (resultSet->next())
> {
> relation = FB_NEW(*database->dbb_permanent) Relation
> (database, -1);
> relation->rel_name = relationName;
> relation->fetchFields(connection);
> addPendingRelation (relation);
> }
> return relation;
> }
>
> The lifetime of the relation objects created by Transaction is the
> life of the transaction. Temporary relation objects currently contain
> minimal data, but this can be expanded as required. Relation objects
> are current just deleted. Sometime we'll probably have to cut over to
> reference counting.
>
>
|
|
From: Jim S. <ja...@ne...> - 2004-06-10 17:08:26
|
Alex Peshkov wrote: > > And what about 'DROP TABLE/VIEW'? Dropped relation will be found in > the transaction, which issued this command. May be 2 lists of pending > relations - new and dropped? And before return check, has not given > relation got in the second list. Certainly, it will be necessary to > add relations to this list from drop_relation() code. You're right -- there certainly is a problem there. Tables can be added then dropped then added and dropping. Looks like I have more book-keeping to do. Sigh. -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
|
From: Paul R. <pn...@ja...> - 2004-06-14 20:30:08
|
> Alex Peshkov wrote: > > > > > And what about 'DROP TABLE/VIEW'? Dropped relation will be found in > > the transaction, which issued this command. May be 2 lists of pending > > relations - new and dropped? And before return check, has not given > > relation got in the second list. Certainly, it will be necessary to > > add relations to this list from drop_relation() code. > > You're right -- there certainly is a problem there. Tables can be added > then dropped then added and dropping. Looks like I have more > book-keeping to do. Sigh. To date, I haven't found the time to investigate how other database systems implement temporary tables. However, it would seem to me that the above code can be usefully re-used to implement temporary tables for Firebird -- assuming the mechanism allows for mixing DDL and DML. Also, it seems to me that on the topic of "metadating without commitment" we are on the downward complexity slope. I believe it was Benjamin Franklin who once said "I wouldn't give anything for simplicity before complexity, but I would give anything for simplicity after complexity". Wise words. Paul Ruizendaal |
|
From: Jim S. <ja...@ne...> - 2004-06-15 11:23:48
|
Paul Ruizendaal wrote: >To date, I haven't found the time to investigate how other database systems >implement temporary tables. However, it would seem to me that the above code >can be usefully re-used to implement temporary tables for Firebird -- >assuming the mechanism allows for mixing DDL and DML. > That actually doesn't work. The physical table is materialized until the commit. Between the create table and the commit only partial metadata exists. A number of the critical fields (rdb$relation_id, for example) are misleading or just plain wrong. >Also, it seems to me that on the topic of "metadating without commitment" we >are on the downward complexity slope. I believe it was Benjamin Franklin who >once said "I wouldn't give anything for simplicity before complexity, but I >would give anything for simplicity after complexity". Wise words. > > > Alas, it's not that simple. We have history to deal with. Among the many problems, however, since uncommitted DDL was never a planned feature, nobody has ever decided or written down what the rules actually are or should be. |
Thanks for helping keep SourceForge clean.
X