New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ResetDatabase does not work with multiple schemas #495
Comments
Hi @Qronicle, did you configure both object managers in the config? zenstruck_foundry:
database_resetter:
orm:
object_managers:
- default
- other |
It's not a different object/entity manager though, we only have the default manager. One example of how we use schemas, is to have a separate one for our audit trail, which we define like this on the entity:
This schema is not configured in any way with the global doctrine settings. |
Ok, I didn't know multiple schema's in the same OM was possible. So is the issue that |
Yeah, I was just adding an edit that I would understand if you think this is more of a Doctrine issue (which it has been since 2016, if I take a look at their issue tracker.) But since this looks like an easy fix in this package, I thought it was worth a shot. Otherwise I'll have a stab at overriding the method in our project, but that might prove difficult with all those final non-service-container-injected classes. (Although I might be missing something, only had a quick look just now) |
So to confirm, your fix is to use Oh, I just confirmed that Question about your use case though - if |
Can you link this issue here for context? I can't find it. |
About schema:drop: It removes all tables, just not the schemas. I guess if you would compare mysql and postgres to a filesystem; mysql would have a file for each table in the mysql root dir. Postgres has subdirs for each schema that contain the table files (by default it puts tables in the "public" dir). Dropping the schema removes all table files, not the schema dirs. Doctrine issue: doctrine/DoctrineBundle#548 - it's closed though (but I'm pretty sure I've read this on multiple occasions on different places, maybe in combination with migrations?) Other suggestion: instead of replacing the existing functionality, you could also make it a new reset mode or something else configurable |
Got it, thanks for the explanation! @nikophil, could this in anyway be related to #458/#455?
If swapping |
I'll give it a shot :) |
Seems like it's failing on all fronts, I'll retest some things locally to see what I messed up :/ |
Okay, three conclusions:
|
Heh, ok, glad you got it sorted. So to clarify, |
Yes, for me it now works using either the migrate reset mode, or using the schema reset mode with my fix. Without the fix it throws an exception like
|
I can see the command |
I tested the |
doctrine acts in a really weird way with postgre's schemas: in all my auto-generated migrations, I have to remove a line where it adds a sql statement with
@Qronicle do you understand why when you have only one schema, the error does not occur? how I understand the problem, it should occur as well, since it does not drop the schema but tries to re-create it 🤔 |
Sorry, I don't have much time for testing today, but yeah, schemas do seem to behave a bit inconsistent. For example we also run an event listener to prevent Doctrine from creating empty migrations because of schema usage. |
[Version: 1.35]
We're having issues with the
ResetDatabase
trait ever since we introduced new schemas to our PostgreSQL database. (In addition to the default "public" scheme, that is.)After a little digging I found that the issue lies with how the database is cleared in the
ORMDatabaseResetter::dropSchema
method. Thedoctrine:schema:drop
command does not seem to drop the schemas, butdoctrine:schema:create
tries to recreate them anyway inORMDatabaseResetter::createSchema
, which throws an exception.I can fix it (for me) by just executing the
doctrine:schema:update
command instead, inORMDatabaseResetter::createSchema
. I'm pretty sure this will work for non-postgres platforms as well.The text was updated successfully, but these errors were encountered: