First off, this issue comes to light long before Postgres comes into play
and thanks to my dear friend DTrace, I think I've managed to workout where
the problem is, however I'm not sure how it should be resolved. I've also
included habari-dev for visibility (just in case there are devs who aren't
on the user list) and further discussion.
First, I set off a simple dtrace script as follows:
# dtrace -x bufsize=300m -n function-entry'{printf("called %s() in %s at
line %d\n", \
copyinstr(arg0), copyinstr(arg1), arg2)}' -q -o file.out
The output is a bit confusing and not quite 100% accurate in some places, eg
the "line 88" lines, but it does provide enough information to trace the
function call ordering.
I then searched for the first instance of db.php in the resulting output
file and back tracked a couple of steps and this is what we see (output and
paths truncated for brevity):
---
[...]
called main() in /.../hb/system/classes/user.php at line 88
called class_exists() in /.../hb/index.php at line 90
called method_exists() in /.../hb/index.php at line 90
called identify() in /.../hb/system/classes/user.php at line 106
called __construct() in /.../hb/system/classes/user.php at line 89
called default_fields() in /.../hb/system/classes/user.php at line 57
called array_merge() in /.../hb/system/classes/user.php at line 58
called __construct() in /.../hb/system/classes/queryrecord.php at line 59
called get_params() in /.../hb/system/classes/utils.php at line 28
called is_array() in /.../hb/system/classes/utils.php at line 29
called array_merge() in /.../hb/system/classes/queryrecord.php at line 29
called exclude_fields() in /.../hb/system/classes/queryrecord.php at line 60
called is_array() in /.../hb/system/classes/queryrecord.php at line 85
called __autoload() in /.../hb/index.php at line 61
called strtolower() in /.../hb/index.php at line 55
called main() in /.../hb/system/classes/userinfo.php at line 88
called class_exists() in /.../hb/index.php at line 90
called method_exists() in /.../hb/index.php at line 90
called __construct() in /.../hb/system/classes/userinfo.php at line 61
called __autoload() in /.../hb/index.php at line 11
called strtolower() in /.../hb/index.php at line 55
called main() in /.../hb/system/classes/db.php at line 88
called __autoload() in /.../hb/index.php at line 9
called strtolower() in /.../hb/index.php at line 55
called main() in /.../hb/system/classes/singleton.php at line 88
called class_exists() in /.../hb/index.php at line 90
called method_exists() in /.../hb/index.php at line 90
called class_exists() in /.../hb/index.php at line 90
called method_exists() in /.../hb/index.php at line 90
called table() in /.../hb/system/classes/db.php at line 11
called instance() in /.../hb/system/classes/db.php at line 81
[...]
---
In the output we can see our call to table() (2nd last line), but it's the
further up in this output that it gets interesting. The constructor for
userinfo.php seems to have initiated the autoloading of db.php. Why?
Well, the constructor in userinfo.php calls DB::table():
---
class UserInfo extends InfoRecords
{
function __construct ( $user_id )
{
// call parent with appropriate parameters
parent::__construct ( DB::table('userinfo'), 'user_id',
$user_id );
}
}
---
This is happening before any instance of DB has been instantiated, which
makes sense as we're only running the installer code and haven't even
reached the point of selecting a database, so won't have setup a DB
connection yet.
Commenting out the line (and reversing the previous suggested change) allows
the installer to continue and work as expected, however it's not a usable
solution as you then get PDO errors when logging in.
So I followed back through trying to workout why we're trying to call
userinfo anyway, and found that the user.php constructor is responsible for
this:
---
public function __construct( $paramarray = array() )
{
// Defaults
$this->fields = array_merge(
self::default_fields(),
$this->fields );
parent::__construct($paramarray);
$this->exclude_fields('id');
$this->info = new UserInfo ( $this->fields['id'] ); <<<------
HERE
/* $this->fields['id'] could be null in case of a new user. If so,
the info object is _not_ safe to use till after set_key has been called.
Info records can be set immediately in any other case. */
}
---
What is interesting is the comment immediately below it. Putting in a
simple check for null allows the installer to continue and display, however
it doesn't seem to work correctly when you click submit as you then get a
"Call to a member function set_key() on a non-object in
/.../hb/system/classes/user.php on line 122" error, which isn't surprising
as it's expecting $this->info to already exist. A screen refresh seems to
then get things working as expected.
So, should this be fixed:
a) in user.php where an instance of UserInfo is being created in the
constructor by moving the creation elsewhere in the class?
b) in userinfo.php where the actual DB::table() call is taking place by
adding a check for a DB instance?
c) in db.php where the table method is being defined by having it check
for a DB instance?
d) else where?
What does everyone else think?
I'm pretty confident this is a bug, so have raised ticket #779 with the
general contents of this email.
Cheers,
Colin
On Fri, Nov 28, 2008 at 2:23 AM, Chris Meller <[EMAIL PROTECTED]>wrote:
> For the record, Postgres requires version 8.3 to run currently, and no one
> has fixed the Postgres schema since all the ACL and timezone changes were
> made.
>
>
> On Thu, Nov 27, 2008 at 1:49 PM, D'alessandro <[EMAIL PROTECTED]>wrote:
>
>>
>> Well i am up and running. Thanks again to everybody that chipped in.
>> And thanks Colin for that line of code.
>> Will try everything out and report if there are any issues.
>>
>> Cheers,
>> D
>>
>> On Nov 27, 11:31 am, "D'alessandro" <[EMAIL PROTECTED]> wrote:
>> > Colin,
>> >
>> > thanks a lot for the tip. I will try it out and let you know what
>> > happens on my end.
>> > Hope this can be ironed out since i got another friend with the same
>> > problem on a different hosting company...
>> >
>> > Cheers,
>> > D
>> >
>> > On Nov 27, 11:15 am, Colin <[EMAIL PROTECTED]> wrote:
>> >
>> > > Well, initial testing seems to indicate something appears to be
>> calling
>> > > "DB::table()" before the "DB::instance()->connection" object has been
>> > > created, though I've not been able to identify what yet.
>> >
>> > > Changing the table() function in db.php to the following:
>> >
>> > > ---
>> > > public static function table( $name )
>> > > {
>> > > if ( NULL == DB::instance()->connection ) {
>> > > return TRUE;
>> > > }
>> > > return DB::instance()->connection->table( $name );
>> > > }
>> > > ---
>> >
>> > > ... seems to allow things to continue and work, however I've not
>> tested much
>> > > more than attempting to insert a couple of posts and comments.
>> >
>> > > Maybe someone with a bit more knowledge of this part of the code could
>> > > comment.
>> >
>> > > I'll keep looking into this tomorrow.
>> >
>> > > HTH,
>> > > Colin
>> >
>> > > On Thu, Nov 27, 2008 at 3:47 PM, Colin <[EMAIL PROTECTED]> wrote:
>> > > > Oh yes, my testing is on a standalone Solaris system that is already
>> > > > running an instance of Habari that was installed quite some time
>> ago, not
>> > > > the MT server.
>> >
>> > > > Will let you know how I get on.
>> >
>> > > > On Thu, Nov 27, 2008 at 3:10 PM, Colin <[EMAIL PROTECTED]> wrote:
>> >
>> > > >> I've just attempted a new install of Habari using the latest SVN
>> code and
>> > > >> I've encountered the same issue.
>> >
>> > > >> I'll do some digging and see what I come up with.
>> >
>> > > >> On Thu, Nov 27, 2008 at 2:23 AM, Matt Read <[EMAIL PROTECTED]>
>> wrote:
>> >
>> > > >>> Try getting the latest version from SVN. the installer was broken
>> a
>> > > >>> couple of revisions ago.
>> >
>> > > >>> On Wed, Nov 26, 2008 at 8:35 PM, D'alessandro <
>> [EMAIL PROTECTED]>
>> > > >>> wrote:
>> >
>> > > >>> > On Nov 26, 6:29 pm, "Michael Harris" <[EMAIL PROTECTED]
>> >
>> > > >>> > wrote:
>> > > >>> >> 2008/11/27 D'alessandro <[EMAIL PROTECTED]>:
>> >
>> > > >>> >> > On Nov 26, 6:02 pm, "Michael Harris" wrote:
>> >
>> > > >>> >> >> Habari doesn't show SQLite as an option ? Odd. Sure, try
>> with
>> > > >>> MySQL.
>> >
>> > > >>> >> > Well the thing is i do not even get to the installer
>> screen... i get
>> > > >>> >> > that error i mentioned in my first post.
>> >
>> > > >>> >> My mistake, I thought this was after you were trying to
>> install.
>> >
>> > > >>> > No worries, i got carried away too.
>> >
>> > > >>> >> > I did setup a postgreSQL and a MySQL on my server but like i
>> said i
>> > > >>> >> > can't even get to the installer screen for habari when i go
>> to my
>> > > >>> >> > install place. So i can't do anything... alredy tried to to
>> the
>> > > >>> >> > checkout again and i get the same thing.
>> >
>> > > >>> >> If you don't even get to the installer, Habari doesn't know
>> anything
>> > > >>> >> about your databases. I'm stumped for the moment, I'm afraid.
>> >
>> > > >>> > Yeah i have seen the installer screen and i know that you pick
>> your db
>> > > >>> > etc there, so yeah i guess the db type at the moment is not the
>> issue.
>> >
>> > > >>> >> Is this a completely fresh install ? Do you have a config.php
>> file
>> > > >>> already ?
>> >
>> > > >>> > Completely fresh. No config file.
>> >
>> > > >>> > --
>> > > >>> > D
>> >
>> > > >>> --
>> > > >>> Matt Read
>> > > >>>http://mattread.com
>> >
>> > > >> --
>> > > >> Colin Seymour
>> > > >> Blog:http://www.colinseymour.co.uk
>> > > >> Tech Stuff:http://www.lildude.co.uk
>> >
>> > > > --
>> > > > Colin Seymour
>> > > > Blog:http://www.colinseymour.co.uk
>> > > > Tech Stuff:http://www.lildude.co.uk
>> >
>> > > --
>> > > Colin Seymour
>> > > Blog:http://www.colinseymour.co.uk
>> > > Tech Stuff:http://www.lildude.co.uk
>>
>>
>
>
> --
>
> Woody Allen - "I will not eat oysters. I want my food dead. Not sick. Not
> wounded. Dead."
> >
>
--
Colin Seymour
Blog: http://www.colinseymour.co.uk
Tech Stuff: http://www.lildude.co.uk
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/habari-users
-~----------~----~----~----~------~----~------~--~---
