Support for DB2 databases?

good that there is a solution.
but i don't like the idea that we need to pass the id to the getfunctionsql() too.
can't you get this information internally from db2? maybe meta information about the current row...?

All Unit tests have run (with only core, search, and 4 graphics modules installed), and I get only 4 errors:

IndexDotPhpTest.testHttpRedirect
PhpVmTest.testHeader
SessionTest.testSessionCookieHeader
SessionTest.testShouldSaveSession

All of which you've said were likely not database related.

Once we've finalized what to do about the BIT_OR UDF issue (requiring the G_ITEMID as well), I'll grab the latest build and try again with all modules installed.

right now there's only 1 use of this BIT_OR and we use GROUP BY there.
what if we use it in another query without GROUP BY? then your UDF wouldn't work anymore, unless we pass in a constant as first argument, right?
something along the lines
list ($ret, $bitOr) = $storage->getFunctionSql('BIT_OR', array(1, '[GalleryAccessMap::permission]')); // if no group by is used.

changes committed.

> what if we use it in another query without GROUP BY? then your UDF wouldn't work anymore,
> unless we pass in a constant as first argument, right?

Sort of. DB2 locates UDF code based on its 'signature' (schema, name, and datatype of args), so this UDF will not work at all without the exact args "int, varchar(32)". So yes, we will need to always specify *some* integer in arg 1, but it is meaningless to specify any fixed integer. It defeats the grouping logic in the UDF itself.

For example, given a table with only the following data:

C:\MyServer>db2 select * from g2_AccessMap

G_ACCESSLISTID G_USERORGROUPID G_PERMISSION

-------------- --------------- -------------------------------------------------------------------
            13               4 x'3030303030303030303030303030303030303030303030303030303030313131'
            28               4 x'3030303030303030303030303030303030303030303030303030303030313131'
            13              10 x'3030303030303030303030303030303030303030303030303030303131303030'
            28              10 x'3030303030303030303030303030303030303030303030303130303131303030'

  4 record(s) selected.

Running the UDF with hard-coded "1" as arg #1 is simply a cumulative BIT ORing of all values in the G_PERMISSION column, regardless of whatever integer is specified in the invocation.

C:\MyServer>db2 select G2_BIT_OR(1, g_permission) from g2_AccessMap

1
-------------------------------------------------------------------
x'3030303030303030303030303030303030303030303030303030303030313131'
x'3030303030303030303030303030303030303030303030303030303030313131'
x'3030303030303030303030303030303030303030303030303030303131313131'
x'3030303030303030303030303030303030303030303030303130303131313131'

  4 record(s) selected.

So if we need to do a BIT OR with no GROUP BY, a separate UDF (like the previous version of G2_BIT_OR) might be required.

> make sure your webserver has port 800 in its configuration

Yes, it does. I mentioned this only in case you might have thought it related to the errors.

no, i haven't.
have you? let me know what John Lim already knows and then i can contact him.

Ok, posted a new topic:
http://phplens.com/lens/lensforum/msgs.php?id=14602

Valiant,

I just grabbed the current nightly build, and the Installer fails to install the core. The problem is:

2006-02-09 12:58:28 [TMP_SESSION_ID_DI_NOISSES_PMT] db2 error: [42611: [IBM][CLI Driver]
[DB2/NT] SQL0604N  The length, precision, or scale attribute for column, distinct type,
 structured type, attribute of structured type, function, or type mapping "G_VALUE" is not  valid.
 SQLSTATE=42611 SQLCODE=-604] in EXECUTE
("CREATE TABLE g2_CacheMap(
 g_key VARCHAR(32) NOT NULL,
 g_value CLOB(4G),
 g_userId INTEGER NOT NULL,
 g_itemId INTEGER NOT NULL,
 g_type VARCHAR(32) NOT NULL,
 g_timestamp INTEGER NOT NULL
)")

I compared that to my previous generate-sql.php, and I see that there is a new "'TEXT-LARGE' => 'CLOB(4G)',". I don't remember ever deciding that we would use CLOB. If we want to use CLOB then as you can see there will be further porting required, and offhand I don't know how large an effort that will be. Do you want to do this, or go back to VARCHAR(8000) for the time being?

Another thing:
we're storing text / strings as UTF8 data. is there anything to be done for DB2?
can one set the character encoding to utf8 during runtime or is that only a server option in db2?

for mysql, we're doing something similar as drupal did:
http://drupal.org/node/40515

maybe you can figure out the CLOB stuff for RC-2 of G2.1. RC 1 will be released in maybe 30h.
sorry for that, but CLOB / long TEXT / how ever it's called in different DBMS is something that we need.

I've found that the maximum CLOB size in DB2 is 2G. I'll make that change to 'generate-sql.php' and see how that goes.

FYI, I've put the output of the 5 failures here:

http://cpe0013102da23b-cm0f0079804905.cpe.net.cable.rogers.com/misc/Gallery%20Unit%20Tests%20-%20utf-8.htm

I'm working on them.

@session acquireNewPersistentSessionRetryOnCollision:
that PHP warning is expected and we suppress it during runtime. but during tests, we show all errors. we need to add the exact php warning output to the sessiontest.class at the end of the file to the exceptions.

@clob:
excellent. gonna commit it asap, right now fighting with other things.

@testing on linux:
why not install linux as dual boot on your windows box?

With respect to unicode, if it is specified at database creation time, then unicode data will be stored correctly. However, I only have ever used unicode with JDBC. But from testing, as soon as the db is created with unicode, it all works without incident.

The NLS stuff, that I am aware of is more for things like sorting, and date interpreations. Also things like decimal delimiters, etc. You could say that it has a similar effect to what it has on the OS. Where change the territory, and it changes time format, date format, and decimal delimiters, etc.

Hey, Sphericus, good to hear from you.

No problem, your work comes first. I can dig it.

The only part of the Zend-Core pack that is needed for G2 is the 'ibm_db2' PHP extension. But even so, the one shipped with Zend-Core might not be current enough, because I've been having Dan Scott fix bugs that I've been finding in it. See the comments in:

http://codex.gallery2.org/index.php/Gallery2:DB2

Thanks, Sphericus.

> codex doc

Already done. Let me know if that's not sufficient.

> sessionTest.class

Done. It still fails. The only errors I see are these constraint violation errors.

http://cpe0013102da23b-cm0f0079804905.cpe.net.cable.rogers.com/misc/Gallery%20Unit%20Tests%20-%20utf-8%20-%20testAcquireNewPersistentSessionRetryOnCollision.htm

OK, that's a little more informative:

<hr>
(db2): 
                SELECT g2_SessionMap.g_id, g2_SessionMap.g_userId,
                    g2_SessionMap.g_remoteIdentifier,g2_SessionMap.g_creationTimestamp,
                    g2_SessionMap.g_modificationTimestamp, g2_SessionMap.g_data
                FROM g2_SessionMap
                WHERE g2_SessionMap.g_id = '1b370a8bc63928ab7350617193203023' &nbsp; <code></code>
<hr>

getParameter id.anonymousUser for core plugin
errno: 2048, errstr: Non-static method ADOConnection::outp() should not be called statically,
errfile: C:\MyServer\Gallery2\lib\adodb\adodb-lib.inc.php, errline: 926<br>

Hmm, I did find one "::outp" call in my driver, but that's not where the error is occurring (plus, it shouldn't be there anyway, so I removed it... could you also remove it from CVS? (Just remove the whole "if(...)", lines 114 - 116.)

The error is occurring in one of the other ADOdb files... "adodb-lib.inc.php", function _adodb_debug_execute(). I presume that the reason we go into that is because debugging is enabled in the test script.

I presume there's nothing wrong with being in debug mode in the test script. But I'm not sure why this is failing. Is there something declared statically that shouldn't be? Or vice-versa?

Yes, that's the one... that's a left-over from the ODBC driver, and should be removed.

Thanks.

I think I'm making progress.

I jammed a bunch of debug info into the the test, and the fatal error seems to be happening here:

/* 6th persistent session has 5 collisions, should fail with error */
	$gallery->_phpVm = new SessionTestPhpVm($sessionIds);
	$session->_sessionId = '';
	$ret = $session->_acquireNewPersistentSession();
	if ($ret) {
// We do go into here, $ret->getErrorCode() is "3".
	    $this->assertEquals(ERROR_COLLISION | GALLERY_ERROR,
				$ret->getErrorCode(), 'error code');
	    if ( !($ret->getErrorCode() & ERROR_COLLISION) ) {
// We do not go into here
		return $this->failWithStatus($ret->wrap(__FILE__, __LINE__));
	    }
	} else {
	    $this->assert(false, 'should have returned a ERROR_COLLISION, but got no error at all');
	}
    }

Am I right in believing that this should be the fatal error, but is never being reported? If so, I'll dig into the assertEquals() code.

> Adodb files

I'm gonna expose my lack of self-confidence now, but... are we even sure that my hack is the right thing to do? It wouldn't be the first time I came to the wrong conclusion about something.

> we just need to add the properbtw

Care to try that again? "the proper... " what?

> Adodb file

So what are we going to do in this case? If I could get someone to verify that's really the right fix, then we can open the bug report for ADOdb.

> SessionTest.class

Ah, I see now.

According to your debug code, $errstmt is:

So I added the check for that pattern:

	    $expected3 = "/db2_exec\(\) \[<a href='function.db2-exec'>function.db2-exec<\/a>]: Statement Execute Failed/";
//LJM	    if (preg_match($expected1, $errstr) || preg_match($expected2, $errstr)) {
	    if (preg_match($expected1, $errstr) || preg_match($expected2, $errstr) || preg_match($expected3, $errstr)) {

And SessionTest.testAcquireNewPersistentSessionRetryOnCollision now runs clean.

But that $errstr strikes me as being a little generic. I mean, any DB2 error would generate that same error... we're not certain that it was a constraint violation. I think that text comes from the 'ibm_db2' driver itself. I'll mention it to Dan, but I suspect it's like that intentionally. The 'ibm_db2' driver provides db2_stmt_error() and db2_stmt_errormsg() APIs to get specific error msg info, but I'm not sure how they could help us in this case.

Thanks.

I've now started looking into SessionTest.testSessionCookieHeaderAndPersistence.

There are 4 errors in it (actually, looks like 2 sets of the same 2 errors). The first one I'm looking at is:

I put more debug info in the source code, and have verified that in the 'imageframe.CSS' / 'bar' test, when it calls assertEquals(), $session->isPersistent() is true (it should be false), but I don't see where that is being set.

Any suggestions?

(P.S.: I'm a little concerned about these new session failures. Why did they not happen before? Other than moving to a new build of g2, I'm pretty sure the only thing different in the database is that it is now UTF-8, but that shouldn't affect the session tests, should it? Or are these tests new?)

@unspecific error:
well, it would be nice if db2 returned more specific errors, but that's not really much of an issue.
it's just a unit test and it's just db2. since we know that it returns this error, also on duplicate key errors, we can allow this error in this single test, and nowhere else. and that's exactly what we do for pg, although there the error is a little more specifc, but we allow it only for this test anyway.

@ ADOConnection::outp:
i don't see any reason why calling it statically should be wrong.

yeah, let's leave the ::outp thing for now.

@testAcquireNewPersistentSessionRetryOnCollision
are you sure the imageframe and the migrate modules are active?