1

I'm attempting to use the sfDoctrineGuardPlugin in my Symfony 1.4 project. This plugin includes a schema.yml file, which is used to define all the tables involved. The table names take on the form of: sf_guard_user, sf_guard_user_group, sf_guard_user_permission, etc. I'd rather have these tables be named: users, user_groups, user_permissions, etc. Is there a way for me to do this without editing the plugin code directly?

Matt Huggins
  • 81,398
  • 36
  • 149
  • 218

2 Answers2

5

Override those things in your project's schema files:

sfGuardGroup:
  tableName: groups

sfGuardPermission:
  tableName: permissions

sfGuardGroupPermission:
  tableName: groups_permissions

Also, I'd prefer to move them into separate file, say sfDoctinePlugin-schema.yml.

Hope that helps.

Darmen Amanbay
  • 4,869
  • 3
  • 29
  • 50
1

Thats not a good practice, and i would discourage you from doing it.

With that said (and bolded, haha) you should be able to copy the included schema into your project level schema and add the tableName key to each record definition. I know that modify the schema in this way works generally speaking because i do it regularly to add extra columns to sfGuardUser instead of using a full blown profile class... i assume that modifying the table name would work as well.

That should after building the db you should see your table names. The thing is if there are cases in the actual plugin code where someone has hard coded the table name instead of using the alias defined in the model things may not work. I dont know that there are any situations like this, but you should test thoroughly before moving on with the project.

prodigitalson
  • 60,050
  • 10
  • 100
  • 114
  • Why is it not considered good practice? Isn't it worse practice to name a table after its implementation (which can change) rather than naming it to reflect what it actually represents (which is unlikely to change)? – Matt Huggins Jan 20 '11 at 01:30
  • Perhaps... IMO... when using an Active Record based ORM especially one that uses some kind of build system its more important that the table correlate directly to the model name, so that you know what tables belong with what models at a glance. It seems to me making the table names agnostic is a worse practice in this case, because the table is directly tied to the model. If you switch model implementations then youre most likely going to have to migrate the db schema backing it as well as all the related models so renaming a table would be the least of my worries. – prodigitalson Jan 20 '11 at 01:46