The sfGuardPlugin README specifically mentions a file with the name

sfGuradPlugin/data/fixtures.yml.sample

No such file exists anywhere in the sfGuardPlugin directories.  This
is therefore an serious defect in the REAME.  It must be fixed.
Either change the directions to simply mention the existence of the
file in order for data-load to correctly install the sfGuardPlugin
fixture, or physically change the name of the file in the tar file so
that it actually matches the directions.  With the files as shipped,
the data-load operation will ALWAYS load that particular fixture file
no matter whether or not you perform the copy.

/Joe

On Apr 10, 7:07 am, Fabien POTENCIER <[EMAIL PROTECTED]
project.com> wrote:
> Hi Joe,
>
>
>
> Joe Kelsey wrote:
> > I don't think this is worth a ticket, but it may indicate something to
> > add to the sfGuardPlugin README.
>
> > I am trying to integrate sfGuard into my project by following the
> > directions in the plugin README.  The file describes using the
> > sfGuardUserProfile to add attributes to a separate table to enhance
> > the user attributes.  I want to add attributes to the standard users
> > loaded by the fixture files so that I can have an entire set of
> > fixture files that will completely populate my database to a known
> > initial state.
>
> > The problem is that data-load does not operate the way that the README
> > file describes.  The README file spends a lot of time talking about
> > copying fixture files around, and that just confuses the issue.  The
> > whole cp here or there issue needs to be removed from the file.  The
> > plugin operates independently of the normal user schema.  If you try
> > to copy any files from the plugin into either your schema or data
> > areas, you will fundamentally break operation of everything.  You need
> > to keep these things separate.
>
> You don't need to copy the fixture file. This is just a sample of a
> simple fixture file.
>
>
>
>
>
> > Through experimentation, I have found that the system works well as it
> > is set up.  If you actually try to follow the mistaken instructions in
> > the README, you will completely mess up your database.  It is better
> > to keep everything separate.
>
> > Now, if you have two fixture files that you want to load, how to you
> > effectively make them refer to objects in each others space?  The
> > sfGuardPlugin fixture file just refers to admin, and the data-load
> > procedure converts the admin to an index number as it performs the
> > various inserts.
>
> > Now I want to insert values into my sfGuardUserProfile, names user in
> > my database.  How to I make the foreignReference objects refer to
> > things that haven't been set yet by the plugin fixture?  The basic
> > problem is that my fixture gets loaded BEFORE the plugin fixture.  Is
> > there a way to control this better?
>
> All your fixture files must be in the data/fixtures directory.
>
> The fixtures files are loaded in the fixture file name order. So, if you
> want to change the order, you can just prefix your file names:
>
> 1-some_fixtures.yml
> 2-some_fixtures_that_depend_on_the_previous_one.yml
>
> HTH,
> Fabien
>
>
>
> > I hope that I am presenting my question in a way that everyone can
> > understand.  I am trying very hard to be polite, but everyone seems to
> > want to accuse me of being rude, even though I think I am being
> > polite.  If anyone has issues with my wording, please extract the
> > exact reference you think is rude and tell me why you think so.
>
> > /Joe
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"symfony developers" group.
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/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to