Commit 6b1986fd authored by cvs2svn's avatar cvs2svn
Browse files

This commit was manufactured by cvs2svn to create tag 'COOL_0_0_3-pre2'.

git-svn-id: file:///git/lcgcool.svndb/cool/tags/COOL_0_0_3-pre2@810 4525493e-7705-40b1-a816-d608a930855b
parent c95f77d1
<include_path path=.></include_path>
<use name=CoolKernel>
# Dependency on POOL RelationalAccess (implies some SEAL dependencies) - RAL
# Dependency on SEAL SealServices - Application
# Dependency on SEAL SealUtils - SealTimer
<external ref=POOL use=RelationalAccess></external>
<external ref=SEAL use=Framework/SealServices></external>
<external ref=SEAL use=Foundation/SealUtil></external>
<export autoexport=true>
<lib name=lcg_RelationalCool>
</export>
# This provides at least one plugin
PLUGIN_MODULE := RelationalCool
# TEMPORARY (?)
# Disable multithreading as it gives problems with MySQL/ODBC on RH73
<Architecture name=rh73_gcc323>
EXCLUDEDCOMPILERFLAGS += -pthread
</Architecture>
<Architecture name=rh73_gcc32>
EXCLUDEDCOMPILERFLAGS += -pthread
</Architecture>
// $Id: RalDatabaseSvcFactory.h,v 1.3 2004-12-09 10:22:18 avalassi Exp $
#ifndef RELATIONALCOOL_RALDATABASESVCFACTORY_H
#define RELATIONALCOOL_RALDATABASESVCFACTORY_H 1
namespace cool
{
// Forward declarations
class IDatabaseSvc;
/***********************************************************************
** NB: this class should only be used in _STANDALONE_ applications **
** where a SEAL Context is not explicitly instantiated by the user. **
***********************************************************************
*
* @class RalDatabaseSvcFactory RalDatabaseSvcFactory.h
*
* Factory of standalone RalDatabaseSvc instances.
*
* The factory implementation takes care to instantiate a SEAL context
* and retrieve the RalDatabaseSvc plugin dynamically within the context.
*
* The SEAL context where the service is defined is a singleton
* owned by the factory class: the same service would be returned
* by successive calls to the getService method.
*
* @author Andrea Valassi and Sven A. Schmidt
* @date 2004-12-08
*/
class RalDatabaseSvcFactory {
public:
/// Locate the COOL database service in a standalone singleton SEAL context
static IDatabaseSvc& getDatabaseService();
};
};
#endif // RELATIONALCOOL_RALDATABASESVCFACTORY_H
// $Id: RalDatabaseSvcLabel.h,v 1.1 2004-11-11 08:49:48 avalassi Exp $
#ifndef RELATIONALCOOL_RALDATABASESVCLABEL_H
#define RELATIONALCOOL_RALDATABASESVCLABEL_H 1
namespace cool
{
static const
char RalDatabaseSvcLabel[] = "COOL/KernelServices/RalDatabaseSvc";
};
#endif // RELATIONALCOOL_RALDATABASESVCLABEL_H
// $Id: RelationalException.h,v 1.9 2005-01-14 14:09:53 sas Exp $
#ifndef RELATIONALCOOL_RELATIONALEXCEPTION_H
#define RELATIONALCOOL_RELATIONALEXCEPTION_H 1
// Include files
#include "CoolKernel/Exception.h"
namespace cool
{
/** @class RelationalException RelationalException.h
*
* Base exception class for the relational implementations of COOL.
* Derived from SEAL Exception just like the POOL RelationalException.
*
* @author Andrea Valassi and Sven A. Schmidt
* @date 2004-11-10
*/
class RelationalException : public Exception {
public:
/// Constructor
RelationalException( const std::string& message,
const std::string& methodName );
/// Copy constructor
RelationalException( const RelationalException& rhs );
/// Destructor
virtual ~RelationalException() throw() {};
/// Clone method
virtual seal::Exception* clone() const;
};
/** @class RelationalDatabaseNotOpen
*
* Exception thrown when a database is not open.
*/
class RelationalDatabaseNotOpen : public RelationalException {
public:
/// Constructor
explicit RelationalDatabaseNotOpen( const std::string& methodName ) :
RelationalException( "The database is not open",
methodName ) {};
/// Destructor
virtual ~RelationalDatabaseNotOpen() throw() {};
};
/** @class RelationalDatabaseDoesNotExist
*
* Exception thrown when a database does not exist.
*/
class RelationalDatabaseDoesNotExist : public RelationalException {
public:
/// Constructor
explicit RelationalDatabaseDoesNotExist( const std::string& methodName ) :
RelationalException( "The database does not exist",
methodName ) {};
/// Destructor
virtual ~RelationalDatabaseDoesNotExist() throw() {};
};
/** @class RelationalFolderExists
*
* Exception thrown during folder creation when a folder already exists.
*/
class RelationalFolderExists : public RelationalException {
public:
/// Constructor
explicit RelationalFolderExists( const std::string& fullPath,
const std::string& methodName ) :
RelationalException( "Folder[set] " + fullPath + " already exists",
methodName ) {};
/// Destructor
virtual ~RelationalFolderExists() throw() {};
};
/** @class RelationalFolderNotFound
*
* Exception thrown when a folder does not exist.
*/
class RelationalFolderNotFound : public RelationalException {
public:
/// Constructor
explicit RelationalFolderNotFound( const std::string& fullPath,
const std::string& methodName ) :
RelationalException( "Folder[set] " + fullPath + " not found",
methodName ) {};
/// Destructor
virtual ~RelationalFolderNotFound() throw() {};
};
/** @class RelationalObjectNotFound
*
* Exception thrown when an object does not exist.
*/
class RelationalObjectNotFound : public RelationalException {
public:
/// Constructor
explicit RelationalObjectNotFound( const std::string& pointInTime,
const std::string& objectTableName,
const std::string& methodName ) :
RelationalException( "Object at " + pointInTime + " not found " +
"in " + objectTableName,
methodName ) {};
/// Destructor
virtual ~RelationalObjectNotFound() throw() {};
};
};
#endif // RELATIONALCOOL_RELATIONALEXCEPTION_H
// $Id: ValidityKeyException.h,v 1.1 2004-12-06 20:33:44 avalassi Exp $
#ifndef RELATIONALCOOL_VALIDITYKEYEXCEPTION_H
#define RELATIONALCOOL_VALIDITYKEYEXCEPTION_H 1
// Include files
#include "CoolKernel/Exception.h"
#include "CoolKernel/IValidityKey.h"
namespace cool
{
/** @class ValidityKeyException ValidityKeyException.h
*
* Base exception class for validity key exceptions in COOL.
* Derived from SEAL Exception just like the POOL RelationalException.
*
* @author Andrea Valassi and Sven A. Schmidt
* @date 2004-12-06
*/
class ValidityKeyException : public Exception {
public:
/// Constructor
ValidityKeyException( const std::string& message,
const std::string& methodName );
/// Copy constructor
ValidityKeyException( const ValidityKeyException& rhs );
/// Destructor
virtual ~ValidityKeyException() throw() {};
/// Clone method
virtual seal::Exception* clone() const;
};
/** @class ValidityKeyOutOfBoundaries
*
* Exception thrown when validity key is too low or too high.
*/
class ValidityKeyOutOfBoundaries : public ValidityKeyException {
public:
/// Constructor
explicit ValidityKeyOutOfBoundaries( const IValidityKey& key,
const std::string& methodName );
/// Destructor
virtual ~ValidityKeyOutOfBoundaries() throw() {};
};
/** @class ValidityIntervalBackwards
*
* Exception thrown when since > until in a validity interval.
*/
class ValidityIntervalBackwards : public ValidityKeyException {
public:
/// Constructor
explicit ValidityIntervalBackwards( const IValidityKey& since,
const IValidityKey& until,
const std::string& methodName );
/// Destructor
virtual ~ValidityIntervalBackwards() throw() {};
};
};
#endif // RELATIONALCOOL_VALIDITYKEYEXCEPTION_H
// $Id: timeToString.h,v 1.3 2004-12-14 10:30:30 avalassi Exp $
#ifndef RELATIONALCOOL_TIMETOSTRING_H
#define RELATIONALCOOL_TIMETOSTRING_H
// Include files
#include <sstream>
#include <string>
#include <stdio.h>
#include "CoolKernel/Exception.h"
#include "SealBase/Time.h"
namespace cool {
/// Convert a string date "yyyy-mm-dd_hh:mm:ss.nnnnnnnnn into a seal::Time.
/// The format is the one we used to store dates for both Oracle and MySQL.
inline const seal::Time stringToTime( const std::string timeString )
{
int year, month, day, hour, min, sec;
long nsec;
if ( timeString.size() ==
std::string( "yyyy-mm-dd_hh:mm:ss.nnnnnnnnn" ).size()
&& sscanf( timeString.c_str(), "%4d-%2d-%2d_%2d:%2d:%2d.%9ld",
&year, &month, &day, &hour, &min, &sec, &nsec) == 7
&& timeString.substr(4,1) == "-"
&& timeString.substr(7,1) == "-"
&& timeString.substr(10,1) == "_"
&& timeString.substr(13,1) == ":"
&& timeString.substr(16,1) == ":"
&& timeString.substr(19,1) == "." ) {
bool local = true;
month -= 1; // Months in [0-11]
seal::Time time( year, month, day,
hour, min, sec, (seal::Time::ValueType)nsec, local );
return time;
} else {
std::string msg = "Error decoding string into seal::Time: ";
msg += timeString;
throw cool::Exception( msg, "cool::stringToTime" );
}
}
/// Convert seal::Time into a string in the format expected by stringToTime.
/// Useful to print seal::Time (the default operator<< uses a weird format).
inline const std::string timeToString( const seal::Time& time )
{
bool local = true;
int year = time.year( local );
int month = time.month( local ) + 1; // Months are in [0-11]
int day = time.day( local );
int hour = time.hour( local );
int min = time.minute( local );
int sec = time.second( local );
long nsec = time.nsecond();
char timeString[] = "yyyy-mm-dd_hh:mm:ss.nnnnnnnnn";
int nChar = std::string(timeString).size();
if ( sprintf( timeString, "%4.4d-%2.2d-%2.2d_%2.2d:%2.2d:%2.2d.%9.9ld",
year, month, day, hour, min, sec, nsec) == nChar ) {
return std::string(timeString);
} else {
std::ostringstream msg;
msg << "Error encoding seal::Time into string: " << time;
throw cool::Exception( msg.str(), "cool::timeToString" );
}
}
};
#endif // RELATIONALCOOL_TIMETOSTRING_H
------------------------------------------------
AV's plan for cleaning up the code - 14.12.2004
------------------------------------------------
General ideas:
- Need three or more types of classes, Relational, Ral, Hvs;
for the moment they can stay all in RelationalCool, then we can move them
- Hvs for the moment is only needed to model transient HVS entities
and factor out functionality that is implemented by CondDB stuff too
(eg HvsNode should be - again - a base clas for RelationalFolder)
- Relational classes should contain all the table and column names
and all the algorithmic logic of the relational implementation
- Ral classes should contain only the code that really does table
creation/dropping and row insertion/update/select/delete: the idea
is that one can provide a MySQL or OCCI direct implementation of
the Relational conddb by JUST replacing the Ral classes
==> Main emphasis of this round of cleanup should be to extract out of
the Ral classes the functionality that belongs to Relational
Specific points for Ral classes
- RalDatabaseSvc: OK should remain
- RalDatabaseSvcFactory: OK for now... eventually may be replaced
by a more general DatabaseSvcFactory, which should understand
IDs of the form "ral::mysql:/" or "mysql::mysql:/" and instantiate
a Ralor MySQL database service to handle the same mysql database....
- RalTransaction: should disappear, it should become RelationalTransaction.
The idea is that the user does not manipulate transactions.
All methoids called by the user are encapsulated within a transaction.
Typically, these methods have the form { 1.startTransaction
2.doSomethingInDb 3.commitTransaction }. Such methods should
go to the Relational classes. In particular, startTransaction and
commitTransaction should be achieved withRelationalTransaction, eg
RelationalFolder::findObject(...){
RelationalTransaction transaction( m_db );
m_db->fetchRow(...);
transaction.commit();
... interpret the row and return the object ...
}
RelationalTransaction( RelationalDatabase* db ) {
db->startTransaction( this );
}
The RalDatabase, ie the only Ral aware class, is the one that both
fetches the object and actually starts the transaction:
virtual RelationalDatabase startTransaction( RelationalTransaction t ) = 0;
virtual RelationalDatabase fetchRow(...) = 0;
RalDatabase::startTransaction( RelationalTransaction t ) {
m_session->startTransaction(...);
t.setStarted(); // JUST SETS A FLAG...
}
RalDatabase::fetchRow(...) {
m_session->getCursorForTheQuery.....
}
Forcing the startTransaction method to accept a RelationalTransaction
argument binds the startTransaction to a particular transaction instance,
so that one is not just tempted to call startTransaction instead
of writing "RelationalTransaction t" in the method where t is started.
Eventually, note that RDBMS offer the possibility to start transacions
with a name, so as to have several concurrent isolated transactions
in the same session... passing the argument can just pass the name...
- RalSequence: this should also change as RelationalSequence.
Again, RalDatabase should take care of doing the actual insert/delete
and so on in the database....
I would keep this for quite a while, because I am not sure when
RAL will support native sequences, or provide SYSDATE support.
Eventually one may think of having all sequences in the same table,
each sequence in a separate row, to have fewer tables.
- RalDatabase: this should be the ONLY Ral class (apart from the
databasesvc and its factory) that remains.
NB: for the moment, the methods it is answeriung are of the form
'fetch object from object table with that order'...
Eventually, this could be refactored slightly so that it offers
much higher level services, eg generic table handling, BUT
- we dont want to reinvent RAL
- somewhere the specific choices of how to write the queries in SQL
(eg the order of inserting the arguments) must be made,
and it should be in the RAL specific class
Other points:
- Should make much more uniform the treatment of the various tables
in the code, have a uniform look and feel for defining the column
names and column types. We may think of using typedefs for the
column types (in the static declarations), so that the code is not
forced to make assumptions in setValue/getValue (eg if IValidityKey
is declared as long long but the iovSince column is typedefed
temporarily as long, the code can be written without knowing
that the iovSince is long... it will just force a conversion
from IValidityKey to/from iovSince type, whatever that is)
- It may be (??) useful to have a table class, and derive all
tables that are present in our code from that class.
But not sure, what would this gain exactly?
Maybe we can let RalDatabase handle the base table, and then automatically
all derived tables by inheritance?
- Instead/in any case, it may be useful to split out the various
'namespaces' RelationalObjectTable, RelationalFolderTable and so on
as real classes RelationalObjectTable, RelationalFolderTable, and so on.
Definitely (again!), the look and feel should be more harmonious,
eg column definitions for RelationalObjectTable in file
RelationalObject.h, or RelationalObjectTable.h, not moving
from RalDatabase.h to RelationalDatabase.h and so on...
AOB
- Iterators
Eventually these should become real iterators which retrieve rows in bulk,
say 1000 by 1000, but not N millions rows all together if this is what is
in the table and in the iteration loop. For this reason it should
only have forward iteration. "Freezing" of the database
can be achived by only selecting rows whose insertion time,
or update time, is less than the time at which the iterator
was created....
The number of rows fetched in each roundtrip may be set by the user,
but it may also be an internal detail at the beginning.
That is to say: the initial implementation of the iterator
now returns an ObjectVectorIterator, but eventually
it should return something more complex!
- Update time
The feature outlined above needs an extra "update time" column
that should be changed when for instance the online columns
has +infinity transformed into a real time.
Note that also in the versioning mode you will have the need
for updating the rows (eg "HEAD unti objectId..." column).
// $Id: RAL_feedback.txt,v 1.10 2004-12-06 20:32:22 avalassi Exp $
==============================================================================
PENDING PROBLEMS
==============================================================================
* AttributeList definitions for seal::LongLong and seal::Time
AttributeLists are not defined for these types.
I cannot create columns with these types...
------------------------------------------------------------------------------
* Transaction settings
Oracle readonly transaction uses READ ONLY rather than SERIALIZABLE.
This gets ORA-01466 which is probably an Oracle bug.
Anyway, we should define what transaction mechanism we really want!
Serializable looks safer and better than readonly, but it may block
concurrent users from running at the same time.
------------------------------------------------------------------------------
* SYSDATE date computed by the server
RAL does not offer a way to specify that SYSDATE should be used
in the SQL insert statement.
------------------------------------------------------------------------------
* AttributeList copy constructor and assignment operator
AttributeLists behave differently depending on whether they were built
from a reference or a boost shared pointer specification.
The assignment operator is reliable only in the second case.
The copy constructor gives problems for both.
This was notified to Kuba, Ioannis and Rado.
------------------------------------------------------------------------------
* Set clause syntax for MySQL/ODBC in IRelationalTableDataEditor::updateRows
Oracle requires ":bindvariable", MySQL/ODBC requires "?".
Rado is aware of this and fixed it in his version of the code.
==> Wait till is publicly available and change the COOL code accordingly
(list of files: RalSequence.cpp).
------------------------------------------------------------------------------
* Multi-threading problems with MySQL/ODBC
I had to disable the -pthread switch on RelationalCool because
the application hangs (only for MySQL). The circumstances are
difficult to explain exactly: it happens in RalSequence when
I try to drop a table and then recreate it again. It does not
happen if the table had been dropped using TOra...
Rado is aware of the problem, it may be solved by the next driver of MyODBC.
==> Wait till POOL is built using the new driver and test it
(list of files: RelationalCoool/BuildFile).
------------------------------------------------------------------------------
* ANALYZE TABLE
RAL does not offer a way to compute ANALYZE TABLE COMPUTE STATISTICS.
Note that also MySQL has the ANALYZE TABLE command.
------------------------------------------------------------------------------
* Partitioning and local indexes
RAL does not offer a way to use table partitioning and local indexes.
------------------------------------------------------------------------------
* Problem inserting rows where all values are NULL
This is translated into non-valid SQL:
INSERT INTO "CONDDB_TEST"."COOLTEST_FOLDERS_SEQ" () VALUES ();
I told Ioannis and Rado about this.
==> Can survive for the moment, change code if Ioannis fixes this eventually
==============================================================================
PROBLEMS SOLVED
==============================================================================
* Feature with columnNamesAndTypes()
If you insert a column via insertColumn( columnName, typeName )
and then retrieve columnNamesAndTypes(), the types are not guaranteed
to be the same. For instance, insertColumn for "unsigned long" will
return an "unsigned long" on MySQL (as the native type can be mapped),
while it will return "long" on Oracle because this maps to NUMBER(38).
This causes problems if you try to then insert an attribute value via
setValue<type> into the attribute list, pool::attribute_bad_type
will be thrown.
=> Solution: when filling in the table, do not rely on columnNamesAndTypes():
instead, keep a local copy of the C++ mapping in the tables or in the
C++ code! This solves the setValue() problem.
------------------------------------------------------------------------------
* Feature with IRelationalCursor::currentRow()
Also in this case the same problem appears: the attribute list returned
has a specification that is read from the table description, ie exactly
the same returned by columnNamesAndTypes(). If the previous problem
appeared for setValue(), this appears for getValue(): it is a priory
impossible to know which C++ should be used for getValue(). The only
safe one is string, but this is not satisfactory!
=> Solution: you must use defineOutput() to specify the required format!
------------------------------------------------------------------------------
* NULL values inserted in MySQL third column (POOL_1_8_0)
This is fixed in the HEAD of ODBCAccess since december 3.
There was a bug with the use of STL vectors: push_back changes
the internal memory addresses of all vector elements.