I still fail to see how no one else has run into this problem before, with all the installs that have been done. I haven't looked at any of the code, but I would tend to think returning from DB::table() if there's no connection is only "avoiding" the problem, not actually solving it.
On Mon, Dec 15, 2008 at 2:22 PM, Colin <[email protected]> wrote: > Sorry to dig this one up again. Looks like the issue isn't completely > resolved as I'm now getting the exact same error when attempting to setup a > new multi-site site (ie user/sites/domain.tld). > > I've re-opened the ticket and will try investigate further this evening or > tomorrow morning. > > > > > On Sat, Nov 29, 2008 at 12:07 PM, Colin <[email protected]> wrote: > >> Great work Rick. Works a treat now. >> >> >> >> >> On Fri, Nov 28, 2008 at 7:09 PM, rick c <[email protected]> wrote: >> >>> >>> This should be fixed now, so if you were having problems, update to at >>> least r2905 to see if the problem still exists for you. As arthus >>> said, and lildude's trace shows, the problem related to the attempted >>> creation of an anonymous user. >>> >>> Rick >>> >>> On Nov 28, 12:29 pm, Arthus Erea <[email protected]> wrote: >>> > From a brief glance, it seems this may be an issue with the new >>> > anonymous users. >>> > >>> > Now, on every load, a new UserObject is created. In doing so, I >>> > imagine the constructor would be called. The constructor will >>> > naturally attempt to look up the info from the database, thus leading >>> > to the problem of the database not existing yet. >>> > >>> > I have no idea if this is correct and what the solution might be. >>> > >>> > On Nov 28, 2008, at 5:11 AM, Colin wrote:> 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 >>> >>> >> >> >> -- >> 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 > > > > > --~--~---------~--~----~------------~-------~--~----~ 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-dev -~----------~----~----~----~------~----~------~--~---
