-
Notifications
You must be signed in to change notification settings - Fork 29
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
Dump a Sample Tenant Structure #32
Comments
@BenMorganIO I'm not sure this is going to be a good solution, as when doing the dump it produces sql using searchpath and USE for postgres and Mysql respectively. For postgres, I think set_searchpath is global, which would break concurrent db connections while this was running. Have a look and see what you think: #40 If we decide to go forward with it, I'll add in the functionality to read these files and actually build the schemas from the raw sql. |
Hmmm yeah, doing breaking concurrent db migrations would be bad. Perhaps we could create a text file in priv and do something like: CREATE TABLE "<%= tenant %>"."posts"; |
I think ultimately the way to do this is to permanently have a template tenant existing in the db, then write a pg function to do this copy for you. I'm not sure how pg internally could solve the searchpath problem, but there we wouldn't have the limitations of the command line pg_dump tool |
closing this for now, as it looks like the way that pg handles db dumps and restores is not safe to use in potentially concurrent actions. The sql could be written and strings interpolated to create a safe concurrent sql script, however I suspect that this would be very prone to error as it will be difficult to consider all possible parts of a complete sql dump with various configurations. |
I've been using Apartmentex for a bit and I've been loving how it's practically just a simple wrapper around
Repo
+ sugar.Something that I'm interested in is a DB dump of tenant migrations. This way when you create a new tenant, instead of running migration after migration, you can instead load up some SQL and get the signup process finished earlier.
Perhaps something like a
mix ecto.apartment_dump
. I could set up a dummyapartment
tenant with no prefix (this way it doesn't conflict in case an "apartment" tenant signs up). Then treat it as a normal tenant when you run migrations. Post migrations, a DB dump could get run for just that search path on development to be committed.Thoughts?
The text was updated successfully, but these errors were encountered: