DB Prefix Issues

Hi siromega,
you are right i translate the $db_prefix as an oracle schema. This choice is due to the fact that a lot of drupal objects exceed the maximum oracle allowed length for identifiers (30 characters) .. So treating the prefix as a schema we have 30 characters more to play with. It is also a logically consistent choice because db_prefix is mostly used for multisite, so having site specific objects into a site specific schema is a good thing... If you remove the schema part the long_identifiers handling code came to make thing works... But it'll be slooower... So, i would prefer to let the db_prefix in the schema domain...

Why would you prefer not to use schemas?

Andrea

your code is buggy:

function oracle_get_table_info($table)
{
global $tableInformation;
$table = oracle_prefix_tables('{' . strtoupper($table) . '}');
$schema= oracle_get_table_schema($table);
[...]

is already fixed in the downloadable version i think:

global $tableInformation;

$schema= oracle_get_table_schema(oracle_prefix_tables('{' . strtoupper($table) . '}'));

if (!isset($tableInformation[$schema."|".$table]))

This is the reason why you get: "seq_dp6_access_aid" intead of "dp6.seq_access_aid":

$table = oracle_prefix_tables('{' . strtoupper($table) . '}');

...here the table becomes dp6_access..

the PL/SQL function sequence_for_table wants the primitive table name as table parameter (access) and the db_prefix as schema parameter...

Andrea

May be you can ask your DBA either:

1. To give the drupal user the grants needed to create other users and to manage their objects (not necessarly the DBA ROLE)...

2. To precreate the db_prefix's users and to give the drupal user the ability to manage their objects

About CLOBs:

The reason why CLOBs (they really are BLOBs because PDO_OCI does not support CLOBs actually, and we have to use PDO_OCI instead of oci8 for future release compatibility 7.x driver have to be on PDO_OCI) are separated is that there are statements that does things like:

select distinct field1, field2, blobfield3 from tablex

or

select field1, field2, blobfield3, count(*) from tablex group by field1, field2, blobfield3

or

i'am pretty sure there was i binding problem too, but actually i cannot remember the case...

So we need to have blobs like "simple-type" columns or translating those kind of statements is a nightmare...

Actually BLOB columns are varchar2(4000), once 4000 is exceed the value is translated in B^#and the
real value is inserted into the BLOBS table with an md5 hash to eventually reuse it....

To migrate from the 4.3 data i suggest you to write a pl/sql procedure... You can check the migration.sql that you can find
into the oracle-6***tar.gz root. It is not supposed to be used for the 4.3, but you can find usefull ideas i think...

May be you would like to contribute that procedure to this project once you wrote it! ;)

This DB Prefix thing is interesting... I was discussing with Crell the last week and he said:

"universal availability is a key goal for Drupal" (http://www.garfieldtech.com/blog/orm-vs-query-builders)

...where "universal availability" means also (i think) that you do not have to fight your DBA.. so may be we can:

1. add a parameter in the settings.php to make $db_prefix work in your deployment profile:
i am a bit scared about adding complexity to the driver... it is quite complex right now..
and there are a lot of "dependencies" in the way it works to keep in mind, so i see this
choice risky to support in the long run.

2. Define a better schema granting mechanism, to make a DBA happy. Actually i simply have had no time
to do it. I think there are good tools in oracle to achieve this thing. Remember also that creating schemas in
Oracle does not mean wasting space... (So the space he gave you does not change, eg. use the same DRUPAL
tablespace/s for all the drupal schemas...).

Yes, i think you can ignore the column order..