Support for DB2 databases?

just to be clear:
- after installing g2 and before re-running the installer and hitting save in step 5, do not drop the database or any tables. just right after installing, enter the installer again...

and if hitting save in step 5 (db step) just works, that is, is accepted by the installer without further notice, then something is wrong.

we rely on adodb's function MetaTables to return a list of tables in the current database.
it works in adodb's mysql, pg and oracle drivers.

if that MetaTables call just returns an empty array, then we don't detect the existing installation.

but we also check g2data/versions.dat
don't you have a versions.dat file in your g2data directory?

you'll have to debug install/steps/DatabaseSetupStep.class

your versions.dat file, is it empty or what does it contain?

basically, getVersion() should check versions.dat, getDbVersion should check the row
module core _version
from g2_PluginParameterMap

well, that it doesn't get the db stuff is one thing, but that $versions has a zero length string for installed is weird.
you'll have to debug

modules/core/module.inc function getInstalledVersions()

aarg, weird stuff. sorry for that.

just to be sure:
- when rerunning the instaler, you're not choosing another g2data dir, right? leave all fields in the installer unchanged...

OK, here's one problem.

In getInstalledVersions(),

is returning "C:\g2dataversions.dat". I added a backslash before 'versions.dat' and it now returns a valid value for "installed".

However, I now get a big red error:

And I now have a link that says "Erase data for a clean install". Is that the link that you said I should be seeing to invoke cleanStore()?

@In getInstalledVersions():
yeah, that was a bug. fixed in cvs, thanks. usually, we add the trailing slash in GalleryInitFirstPass (init.inc), but if there are no database tables, this function isn't called in the installer.

yes, this "erase data for a clean install" is what i meant.

that's unrelated. Db2DatabaseStorage.class function getVersion should return the version of the db2 server.

what we're asking for in the DatabaseSetupStep.class of the installer is the installed G2 version.
thus, we're first asking the database for all a list of all g2 tables in the g2 database.
then we're checking if g2_Schema (of course we use the user defined prefix) and g2_PluginParameterMap exist.
then we check the row module core _version in g2_PluginParameterMap to get the installed g2 version.

but the function MetaTables for adodb-db2.inc.php seems to return an empty list, right? can't help you there. that's abug with this db2/odbc thing.

ah, no. the problem is that ODBC / DB2 returns a capitalized list of tables.
pg/mysql/oracle return "g2_PluginParameterMap, g2_PhotoItem, ..."
on windows, mysql returns "g2_pluginparametermap, g2_photoitem, ..." (all lower case)

and db2 seems to return all capital case on windows.

please replace your install/steps/DatabaseSetupStep.class with this file (rename .class.txt to .class again):

http://dev.nei.ch/DatabaseSetupStep.class.txt

no, either i'm having a really bad day and i'm not understanding you or it's exactly what i described in my last post and in this post. odbc_version is totally unrelated to the row
pluginType = module, pluginId = core, parameterName = _version parameterValue = 1.0.10 in your g2_PluginParameterMap.

the odbc_version / db2 version isn't needed here. yes, we call Db2DatabaseStorage::getVersion just to have some debugging information, but it's not related to the string
""The G2 storage directory has a versions.dat file of an old install. But the Gallery database tables don't exist" ".
believe me, i wrote that stuff

and yes, db2level sounds acceptable for Db2DatabaseStorage.class function getVersion(). It's not that important what it returns. maybe just return the whole db2level output.

ok, i've updated http://codex.gallery2.org/index.php/Gallery2:DB2

feel free to edit that page (you just need to register an account on codex.gallery2.org).

i'll commit the capitalized string issue of adodb/odbc/windows today.

Hey, Valiant.

I'm trying to add the admin functionality I haven't added yet ("Optimize database", "Delete database cache" and "System information").

1) "Optimize database"

Looks like what we want to do here is call DB2's "REORGCHK_TB_STATS" stored procedure. However:

- It needs to pass the schema id (the g2 database user account, in my case, 'G2USER'). Is there a variable I can reference to get this?

- It won't work on 'single-user' Windows platforms (95|8, ME, XP). However, I doubt anybody will be doing any serious photo sharing on XP. Would you say that's an acceptable trade-off?

(The reason it won't work on XP etc. is that it requires an authority level SYSCTRL, which is granted to GROUPs, not individual accounts. Since XP does not have the concept of GROUPs, the only way to do it is to make the G2 account a Windows system administrator. I doubt people would be happy to do that.)

2) "Delete database cache"

Already works.

3) "System Information"

I added the following:

    function getVersion() {
        $levelcmd = 'db2level';
        list ($success, $outputArray) = $platform->exec(array($levelcmd));
        return $outputArray;
    }

But it doesn't work. I just get a blank browser screen (which typically happens when there's a PHP syntax error). When I comment out the exec line the browser output comes back, so I know the problem is with that line, but it looks fine to me. Any idea what's wrong with it?

Thanks.

3) Still doesn't work. I still just get a blank browser. Did I miss something?

    function getVersion() {
        $levelcmd = 'db2level';
        list ($success, $outputArray) = $platform->exec(array(array($levelcmd)));
        return implode("\n", $outputArray);
    }

Umm, actually, "$this->_ds->_username" doesn't work either. Apparently "_ds" doesn't exist.

Distinguishing single-user from multi-user Windows in PHP:

I don't know of a definitive way to tell the difference between (for example,) XP and W2K via PHP. On my XP systems, php_uname() returns "Windows NT" and PHP_OS is "WINNT". So it doesn't look like PHP natively distinguishes between them.

Since the ultimate requirement is to determine whether the current platform supports Groups, one method that I thought of was to use getmygid(). On my XP system it returns "0", which sounds reasonable. On systems that do support Groups, I don't know how likely it would be to return "0". As I don't have a W2K system to test it on, I have no idea how foolproof this is (or isn't).

        if ( (GalleryUtilities::isA($platform, 'WinNtPlatform')) &&
             (getmygid() == 0) ) {
            return NULL;
        }
        else {
            return 'CALL REORGCHK_TB_STATS (\'S\', \'' . $this->_username . '\')';
        }

What do you think?

Can you point me to an example of g2 code where a non-fatal warning is reported?

This particular error is rather misleading ("User doesn't have authorization to create a tablespace"). I'd rather compose my own more explicit message rather than just forwarding that one.

OK, will do. Thanks.

good to know that you're making progress!
good to have a basic working driver, now you can gradually add features. and don't forget to backup working code!

don't know, sorry. i'm sure the adodb author can answer this question.

Hmmm, never mind about this. I checked the install.log from my running installation (which uses odbc) and those values are in single quotes.

So never mind, it must be something in the ibm_db2 driver. I'll look into it.

After further investigation, I don't think the order is significant... I went back to ODBC and dumped the vars and the order is the same as with 'ibm_db2'.

$query = "INSERT INTO g2_FactoryMap (g_classType, g_className, g_implId, g_implPath, g_implModuleId, g_hints, g_orderWeight) VALUES (?,?,?,?,?,?,?)". 
$data = array(7) { ["classType"]=> string(13) "GalleryEntity" ["className"]=> string(22) "GalleryDerivativeImage" ["implId"]=> string(22) "GalleryDerivativeImage" ["implPath"]=> string(49) "modules/core/classes/GalleryDerivativeImage.class" ["implModuleId"]=> string(4) "core" ["orderWeight"]=> string(1) "4" ["hints"]=> string(2) "N;" }

BUT...

Notice that the type of $data['orderweight'] is now 'String(1)'. With 'ibm_db2' it is 'int'.

Any suggestions as to where this type is being determined?

Thanks.

I was dumping them in addMapEntry() in "DatabaseStorageExtras.class".

Now I'm working my way back through the stack trace and dumping "$orderWeight" at each step. I found that in registerImplementation() in "GalleryFactoryHelper_medium.class", "$orderWeight" is type int.

The next step back in the stack trace is performFactoryRegistrations() in "CoreModuleExtra.inc", but it's a bit over my head.

I've now traced all the occurrences of the type mismatch problems. I solved them by changing:

In upgrade() in "CoreModuleExtras.inc":

//$ret = $module->setParameter($key, $value);
$ret = $module->setParameter($key, (string) $value);

In performFactoryRegistrations() in "CoreModuleExtras.inc":

//'core', $entry[3], isset($entry[4]) ? $entry[4] : 4);
'core', $entry[3], isset($entry[4]) ? (string) $entry[4] : '4');

(Instead of casting $entry[4], I could have quoted or casted all of the 5th values as they are pushed onto the $entry array. Casting $entry[4] is perhaps less obvious, but it's fewer keystrokes. )

In setParameter() in "GalleryPlugin.class":

//$this->getPluginType(), $this->getId(), $parameterName, $parameterValue, $itemId);
$this->getPluginType(), $this->getId(), $parameterName, (string) $parameterValue, $itemId);

Tomorrow I'm going to work on the next problem:

But at least I think there are no more type mismatches.

Let me know what you think about that.

Fantastic, thanks.

I'll proceed with the next problem. ;-)

This must be your turn to stump me... what's "HEAD"?

A few more casting fixes:

modules/core/CoreModuleExtras.inc, _createAdminUser():

//list ($ret, $results) = GalleryCoreApi::fetchUsersForGroup($adminGroupId);
list ($ret, $results) = GalleryCoreApi::fetchUsersForGroup((int) $adminGroupId);

...

//$ret = GalleryCoreApi::addUserToGroup($user->getId(), $adminGroupId);
$ret = GalleryCoreApi::addUserToGroup($user->getId(), (int) $adminGroupId);

modules/core/CoreModuleExtras.inc, _createRootAlbumItem():

//$ret = GalleryCoreApi::addGroupPermission($album->getId(), $groupId, 'core.viewAll');
$ret = GalleryCoreApi::addGroupPermission($album->getId(), (int) $groupId, 'core.viewAll');

...

//$ret = GalleryCoreApi::addGroupPermission($album->getId(), $groupId, 'core.all');
$ret = GalleryCoreApi::addGroupPermission($album->getId(), (int) $groupId, 'core.all');

modules/core/classes/GalleryUser.class, save():

//$ret = GalleryCoreApi::addUserToGroup($this->getId(), $groupId);
$ret = GalleryCoreApi::addUserToGroup($this->getId(), (int) $groupId);

modules/core/classes/helpers/GalleryPermissionHelper_advanced.class, _getAccessListCompacterLock():

//list ($ret, $lockId) = GalleryCoreApi::acquireReadLock($semaphoreId);
list ($ret, $lockId) = GalleryCoreApi::acquireReadLock((int) $semaphoreId);

...

//list ($ret, $lockId) = GalleryCoreApi::acquireWriteLock($semaphoreId);
list ($ret, $lockId) = GalleryCoreApi::acquireWriteLock((int) $semaphoreId);

If you don't mind, please check them in too.

FYI, I'm now at a point in which the Gallery core installs successfully, but I get an ERROR_STORAGE_FAILURE error when I go to Step 10. I'll keep hacking at it tomorrow or the day after. I've been going continuously full-throttle on this for about 36 hours now... need a breather. And a few beer.

Valiant,

I now have the Installer completing successfully, but I happened to notice that I still get the following error in the install.log:

2005-12-21 11:30:32 [] getParameter id.allUserGroup for core plugin
2005-12-21 11:30:32 [] db2 error: [42818: [IBM][CLI Driver][DB2/NT] SQL0401N  The data types of the operands for the operation "=" are not compatible.  SQLSTATE=42818
 SQLCODE=-401] in EXECUTE("DELETE FROM g2_UserGroupMap WHERE g_userId=5 AND g_groupId='2'")

But I don't get a stack trace with it (presumably because it's considered non-fatal), so I don't know where to start tracking this.

Any suggestions?

Hmm, the stack trrace doesn't seem to take me back far enough.

<pre align=left> &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp; <font face="Courier New,Courier">ADOConnection._Execute(DELETE FROM g2_UserGroupMap WHERE g_userId=5 AND g_groupId='2')</font><font color=#808080 size=-1> % line  836, file: <a href="file:/C:\MyServer\Gallery2\lib\adodb\adodb.inc.php">adodb.inc.php</a></font>
 &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp; <font face="Courier New,Courier">ADOConnection.Execute(DELETE FROM g2_UserGroupMap WHERE g_userId=? AND g_groupId=?, Array[2])</font><font color=#808080 size=-1> % line  985, file: <a href="file:/C:\MyServer\Gallery2\modules\core\classes\GalleryStorage\DatabaseStorageExtras.class">DatabaseStorageExtras.class</a></font>
 &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp; <font face="Courier New,Courier">DatabaseStorageExtras.removeMapEntry(GalleryUserGroupMap, Array[2])</font><font color=#808080 size=-1> % line  455, file: <a href="file:/C:\MyServer\Gallery2\modules\core\classes\GalleryStorage\DatabaseStorage.class">DatabaseStorage.class</a></font>
 &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp; <font face="Courier New,Courier">DatabaseStorage.removeMapEntry(GalleryUserGroupMap, Array[2])</font><font color=#808080 size=-1> % line  323, file: <a href="file:/C:\MyServer\Gallery2\modules\core\classes\GalleryStorage.class">GalleryStorage.class</a></font>
 &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp;  &nbsp; <font face="Courier New,Courier">GalleryStorage.removeMapEntry(GalleryUserGroupMap, Array[2])</font><font color=#808080 size=-1> % line  115, file: <a href="file:/C:\MyServer\Gallery2\modules\core\classes\interfaces\GalleryUserGroupMap.inc">GalleryUserGroupMap.inc</a></font>
</pre>

To fix this at the lowest level I need to find where the '$data' is set that is being passed into removeMapEntry().

Thanks.

OK, I have the install completely working now, and the main.php runs without error.

However, even after I login with the admin id I am not given the option to create an album.

Any suggestions where to start looking, or should I just start with main.php and work my way through the code?

Trust me, I'm already very familiar with the process of logging in, and the resultant change of fields in the browser. In the last few months I've done so more times than I care to count. Like I said, "even after logging in...". My login does complete successfully, the indicators in the bottom-right corner do reflect my logged-in "lmenard" account, and I do have the "Site Admin" and "Logout" links in the top-right corner. So the login does seem to have worked according to those indicators, but I don't have the actions available in the left-hand side.

So what I'm asking is "Since you are much more intimately familiar with the flow of the application logic than I am (and given the symptoms described above), do you have any suggestions as to where in the code I should start to look?". Or should I just start in "main.php" and start tracing the hell out of it?