OK - following a number of problems with my development machines ( caused mainly by unnecessary 'improvements' to linux :( ) I now am back to a stable platform.
I run Eclipse and phpEclipse for php development, and now have SVN running in parallel with CVS although I'm not seeing the same facilities as yet. The CVS views tag files I've updated, but I may simply not be getting that on SVN becuase I'm using anonymous checkout.
First problem once I had a clean chcekout. No install menu. Not quite sure on this, but running install.php direct at least started things up. I had to manually reconfigure config.dist for firebird before I could proceed to building the tables. Just a few minor problems and I now have the installer running through to completion.
I've had to strip the 'NULL' sql, firebird only expect 'NOT NULL' - so I created a self::$NULLABLE which is either ' NULL' or ' ' and that sorts it transparently.
Also DEFAULT has to be set before NULL, but that only affects one table, so I've created a special for firebird there ( I think Oracle expects the same order ).
But the main problem was 'get_site_setting' which kept failing because 'execute had already been run' - I've dropped the 'static $statement' for the time being, and that gets around the problem for the moment.
- should we be able to select the database as per the instructions on the wiki?
Presently, while I can get through the installer, any of the options on the final page just result in a blank screen, which I'll have to come back to later.
Forgot to add that lots of large character fields in user table prevent it being created. If we need 32000 characters in a field - it should be a blob entry .... I've trimmed them back to 1024 for now via $TEXT_TYPE entry for firebird.
OK probably talking to my self here ( ? Is this the right list for developers )
Eclipse SVN client does not provide a sync view so you have to simply manage via the main project view :(
/phpgedview/ just gives a white screen ….
( I'll come back to this later, but php.ini would seem to need output_buffered=0n rather than the default =4096)
config.dist had to be patched to enable firebird, then a call direct to /phpgedview/install.php at least worked …
I have patches for
which at least allows PGV to install on firebird - after manually creating an empty database (PDO has no facility to create it for firebird)
Patches to functions_db.php to remove 'INDV' and similar entries being used as parameters. firebird does not like that
functions.php has had 'Mutex' commented out until I can work out why it causes apache seg fault.
MAIN problem may well be that the firebird PDO driver has too many bugs unfixed in 5.2, apparently only 5.3 branch has been fixed - and that introduces it's own set of major rework - and is not available for fedora yet anyway. I've moved to the windows box to see what I can do next …
Yes, I'm afraid you are probably alone. Don't know anyone that uses the set up you describe, so your patches are probably only of use to yourself.
Also, no this is not the best place for these discussions. This is a general discussion area for users. There is also the Help forum, but its use is fairly obvious.
There is a Developers forum, but only accessible to Developers. Of course they do read these posts too, but the lack of comments suggets even they are not particularly keen to get involved.
Well it does look as if I need to be on the developers list ….
I can't see any way the current installation instructions can work for ANY user …
If there is an empty config.php file, then there is no way to get to the installer UNLESS you add install.php - and then you don't get a chance to select the database anyway!
And having switched to windows because that is the only working PHP5.3 I have, I'm hitting 5.3 problems as well as windows problems with the generic code - even before any of the database stuff :(
I don't mind debugging stuff - but when I HAD a fully functional windows/linux build on firebird having to start again from scratch is a pain.
OK - first thing I was missing was that config.dist has to be copied to config.php when working from SVN ….
<<probably talking to my self here>>
You are not. I've already coded the necessary changes. However, I need to do a bit more testing before I submit them to SVN, as I need to make sure the new code (a) works for other DBs, when installed from scratch and (b) the upgrade from previous DBs still work.
<<after manually creating an empty database (PDO has no facility to create it for firebird)>>
This is the same for all DBs.
<<only 5.3 branch has been fixed - and that introduces it's own set of major rework>>
PHP5.3 works fine. I am using it now. You just need to set the ERROR_REPORTING level to ignore deprecated items.
<<OK - first thing I was missing was that config.dist has to be copied to config.php when working from SVN>>
This necessary, otherwise developers "accidently" submit changes to SVN, overwriting everybody elses config (and telling us their DB password as well!)
<<the lack of comments suggets even they are not particularly keen to get involved>>
Normally, that's the case. However, on this subject, I am keen. I have just been very busy.
<<Patches to functions_db.php to remove 'INDV' and similar entries being used as parameters. firebird does not like that>>
Can you elaborate?
I am fighting a number of problems here and it may be PHP5.3, PDO:firebird, or windows ;)
Some of the PDO:firebird problems have been fixed in 5.3 but not back ported, I have PGV running on 5.3/windows, just had to add the timezone setting - but I will not run in production with 'ignore deprecated items' on my customer sites. This requires a major rework to get my other applications up from 5.2 - hence my main production machines are still 5.2.
On the 5.3/windows box I have done a clean install from scratch building a firebird database. and only a couple of changes to the schema code ( just handling NULL/DEFAULT differences )
The problem I keep hitting and which I have been going around in circles on for the last few hours is 'count_all_records' !
First problem was that PDO:firebird would not accept 'INDI' as a parameter - prepared statements *IN* firebird must have a fixed set of field names. But I have now established that this six line union is not actually working correctly IN firebird. I have five lines of results running it manually against the database, but when running the fetch in PDO:firebird it crashes without any log messages and a white screen if I use more than 2 lines in the union. This is not a PGV problem and so I'm working on it in ADOdb at the moment to see what is going on - as I know the code in there and can actually play with things. Importing gedcom crashes as well - even on 5.3 - so I'm not sure on the reported fixes to PDP:firebird. I remember last time I looked at PDO how painful it was to debug the drivers and to be honest if I find too much broken then I'll just revert from PDO. I don't want to use it in my comercial software!
( Now this shitting forum update is pissing me off again - what happend to new line! )
OK - getting this a lot more under control, but I'm hitting the limitations of PDO I think!
One problem is with the cached queries. I am getting a lot of 'Attempt to reopen an open cursor ', mainly now from the second or third call when adding multiple items such as places.
But the main problem is the use of BLOB's as large text fields. It does not look as if these are being managed as strings when using then for the gedcom records. THAT is what was crashing my gedcom load. I've regigged the schema to give me large varchar fields for the gedcom entries, but this is just a bodge. It would seem that oracle can work with strings into CLOB fields, but in PDO 'LOB' can only be used with streams - not with simple strings.
I'm not quite sure which way to go now. As I had anticipated PDO simply does not provide the necessary facilities but as long as the gedcom entries are kept below 32k there are work arounds. But the caching is simply not suitable for a database that has it's own internal handling for that ….
At least I've managed to load the current gedcom - after increasing the available memory, so I can look at other areas now.
(P.S. what is planned for 'SKIP'? LIMIT seems to be catered for, but SKIP is quite useful when limiting some of the longer lists that I'm now generating.)
<<what is planned for 'SKIP'?>>
PGV doesn't currently use OFFSET/SKIP on limit queries, and has no plans to do so.
<<as long as the gedcom entries are kept below 32k>>
The gedcom format specifies that records should never be longer than 32K.
what is planned for 'SKIP'?
PGV doesn't currently use OFFSET/SKIP on limit queries, and has no plans to do so.
Well I need to reduce the number of people on some pages to a more suitable level, and so a limit on the number of records displayed will be useful.
But I have a copy of PGV running on ADOdb again, and all of my problems have gone away. Next step is to make things like SUBSTRING database independent, and I need to switch UTF8 back on now that I have a stable database. There are still a few areas that I need to convert, but I am operational in a reasonable number of areas …. certainly a lot more than I was this morning!
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.