-
Notifications
You must be signed in to change notification settings - Fork 2
[Question] Can the schema for the migrations (tables) be configurable instead of using public? #10
Comments
Hey, Yes right now the jobs tables are put into the public schema always. I'm totally fine with making that not the case though. I can take a look at changing this, this weekend. However if you wanted to tackle it yourself the general idea is:
|
Hi, Thank you so much for the prompt response. Yes, I completely agree with the steps you mentioned. However, unfortunately I'm not a Kotlin developer and I don't feel comfortable applying those changes myself. If this is something that you and/or your team can tackle for us sometime soon that would be much appreciated. Otherwise, I might have to look around to see if there's a Kotlin engineer that can help my team with this. Thanks |
Hey, tl;dr: this change is going to require us to go to 2.0.0, and have some significant work This is going to be a bit bigger of a breaking change than I was expecting. We're going to need to add an extra argument to every job constructor (which means we'll need to go to 2.0.0). This is because LISTEN/NOTIFY is not actually scoped to the schema level:
This would mean if two people ran coworker on the same database (in two seperate schemas) many errors would crop up. As such we'll need to set the channel names to include the schema name like: Still for it, but it will be big. Thanks, |
Okay I've got a local branch going, that just needs a little bit more work before it's ready for testing. It changes the jobs quite a bit so we can have much less breaking changes in the future (the jobs not get passed a "WorkCreationInformation" class that can have fields added without it being a breaking change). Not to mention it can successfully run in a multiple schemas, at the same time (I'll add tests for this scenario as well). If I were to push the code to sonatype's staging repository would you be able to check it out, and ensure it works for you all (The code would also be on github, and documentation would be updated)? |
Hi, Thanks for all your work on this. Sure. Just let me know where I can get the new code from including the documentation and i will try to test it out as soo a I can. No rush, but when do you anticipate this being ready for our testing? Just want to know how/when to account for this work into our sprint planning. Thanks P.S. Just curious as to what went into the decision of making the new schema variable a part of each job constructor. I would've thought that you would want to keep the schema as an environment config variable and the job(s) wouldn't know anything about it. Yes, that would mean that we would only have 1 schema to work with. I might be missing something, but I'm not sure if having the ability to associate jobs with different schemas adds much. Maybe you're aware of scenarios where that might be beneficial. But I think it might be better to keep the schema as an environment config variable and eliminate the coupling between that and the jobs(s). Please let me know what you think. |
Hi, Any updates on this? Thanks |
Hey, Sorry I missed your previous comment here. I'm currently going through on the weekend, and doing what I can to make sure all works smoothly. The purpose of passing the schema in the constructors isn't so jobs can use a different schema (in fact it's specifically marked: Coworker uses Unfortunately
|
Hi, |
Hey @OleksiiM , I am still working on it, I will update it if something changes. Unfortunately this is quite a large change, and I have many priorities right now. (Even if you exclude the craziness going on in the world). If you’d like to see this sooner, let me know, and I can give you what I’ve done so far. That way you could take it to completion. Otherwise please realize this is a free project, and not my only one. I can only do so much, so fast. Thanks, |
Description
If I'm not mistaken, it seems like the schema for the migrations (tables) is hardcoded to public. Is it possible to make this configurable so that it can be overridden? Our team doesn't want to create tables under the public schema as our app runs under it's own schema and we want to use that instead.
Thanks
The text was updated successfully, but these errors were encountered: