** This issue is now resolved *** DISCLAIMER
I don't want this to seem like a giant bitch-fest over sfDoctrineGuard, it works great thank you for writing it, REALLY. But boy there were some frustrationg moments for me. I would hate to have built a custom authentication class(es?) myself, so I tip my hat to those that do this for free. Thank you so much, and as well to all of you who chimed in to help me, on and off-forum! sfDoctrineGuard And I: A Love Story. Kind Of. However, I'm not sure of the best place to post this, but it may help a weary traveler, I know it cost me more hours than I'm prepared to divulge. The problem was that when working locally on my OSX.5 macbook pro, I found everything was working great. My project started out in October using symfony 1.2 and whatever sfDoctrineGuard was at the time (I used SVN). I had a Ubuntu server set up with mysql 5.0, and all was well. Part I It started going awry when I upped to Symfony 1.4, and fixed a few things via the compatibility. I updated sfDoctrineGuard too. When I deployed (it had been some time as I was working hard locally, keeping the clients in the dark re: a staging server), I found my first problem. When doing a build --all I got errors creating the FKs with no comprehensible error message from mysql. It turned out that the version of mysql I was using locally was different than the server version by enough that the FK label was limited to 64 characters on the server, but not locally. So sfDoctrineGuardPlugin in it's current state would not build on the server. Still won't actually. Here's the error. SQLSTATE[HY000]: General error: 1005 Can't create table './quicksand- staging/#sql-8fc_ce.frm' (errno: 121). Failing Query: "ALTER TABLE sf_guard_group_permission ADD CONSTRAINT sf_guard_group_permission_permission_id_sf_guard_permission_id FOREIGN KEY (permission_id) REFERENCES sf_guard_permission(id) ON DELETE CASCADE". Failing Query: ALTER TABLE sf_guard_group_permission ADD CONSTRAINT sf_guard_group_permission_permission_id_sf_guard_permission_id FOREIGN KEY (permission_id) REFERENCES sf_guard_permission(id) ON DELETE CASCADE Notice the huge key name? sf_guard_group_permission_permission_id_sf_guard_permission_id So I figured I just dump the local schema, upload, export the server data, insert the correct schema and import the data (via a script, of course - I'm not crazy). This got me past that problem. THANKS GEORG for the key tip! I have posted a ticket so hopefully it will get resolved. ** Also not worth making a big fuss over is that sfDoctrineGuard added a REQUIRED and UNIQUE field so now email and username must be unique and not null. This messed up my fixtures (though it was easily fixed) ** Part II After I bypassed the symfony way of doing things, I tried the site. As soon as I started to login, the site went 'Error 500'. Looking in the apache logs, I saw the error [Tue Jan 12 11:25:31 2010] [error] [client xx.xx.xx.xx] Unknown relation alias sfGuardUser So something about sfDoctrineGuard again. The site worked until any reference in sfGuardUserProfile (my own class that referred to sfGuardUser via a FK named User [foreign key: Profile], and I was getting weird errors about sfGuardPermissions, sfGuardUser, and profile (all valid things in my schema). Finally fter digging through lib/model/doctrine for the 15th time, I noticed an "sfDoctrineGuardPlugin" folder with the previous solo folder, "base". Then I realized that the old sfDoctrineGuard stored it's base classes in "base" but the new version stored them in it's own folder, "sfDoctrineGuardPlugin". THere was a class or namespace collision, whatever. Locally it was working by fluke (base was being read first, I guess), but on the server it must have been "sfDoctrineGuardPlugin" that won out. So after deleting the sfGuard* classes in the "base" folder, everything worked! This took me a LOOOONG time to resolve. * blush * Conclusion Wow, I shouldn't have upgraded. I didn't mention anywhere above, but one of the key reasons for my upgrading to 1.4 was doctrine:generate-migrations-diff. I though, "Wow, that's awesome, what a great way to update". However, everytime I generated a new migration there was detritus from sfDoctrineGuard in every itration (it was modifying a bunch of Fks - the same ones each time). Even from a migration-from-schema. * sigh * Probably something I was doing, or a version mis-match. I didn't have time to pursue it, I'm getting deadline-bound and had to move on. In hindsight, I think half of this was my fault, but it wasn't anywhere obvious that: a) There was a difference between the local and server mysql versions significant enough to interrogate. b) the sfDoctrineGuard authors changed the folder structure of the plug-in in lib c) sfDoctrineGuard added a REQUIRED and UNIQUE field so now email and username must be unique and not null. This messed up my fixtures (though it was easily fixed)
-- You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-us...@googlegroups.com. To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en.
