Open Altreus opened 6 years ago
Also the status quo means that you can't get a hold of the $ddl
in order to actually save it to the database if you use deploy
Why are you calling deploy instead of install?
@Altreus Could you help me understand this by saying why deploy instead of install? Otherwise I can't help you and will have to close this.
This is related to this module: https://github.com/Altreus/DBIx-Class-DeploymentHandler-VersionStorage-WithSchema
The module allows you to deploy more than one DBIC schema into the same DB. For modular systems.
This meant that the first schema must install the DH table, but later schemata must not, or it will crash. This meant that I needed to deploy
it but not install
it. I was surprised that deploying a schema did not set its version.
The underlying issue is essentially one of semantics; the implication of having a public deploy
method is that I should be able to use it. And the expectation is that if I deploy a version then it knows it's deployed that version, i.e. it sets the version in the DB.
To work around it I have to manually set the database version in the handler script, whereas I'd really expect DH to handle its own versions:
https://github.com/OpusVL/OpusVL-FB11/blob/master/bin/fb11-dbh#L209-L234
I still think this is an issue, but I don't know whether it can be fixed backwardly-compatibly.
It certainly seems a reasonable "ask" that one DB could contain >1 DBIC schema. The __VERSION
would need to acquire a schema
column, and the creation of __VERSION
would need to become a bit more intelligent.
Interesting historical note: the original reason I wrote DBICDH was to have multiple schemas in one database. It supports it just fine as is and as far as I know that company still has related databases in some places.
@frioux That IS interesting - did the different schemas have independent versions, or was it one version = all the schemas?
Different versions; I'm not sure how they could be different schemas otherwise :)
Yes, we still have a multi-schema database over here. The versions are indeed independent but we keep the two versions matched with shim migrations.
@wesQ3 Are you using DBICDH?
@mohawk2 Yes, we use DBICDH. Our split-schema was implemented back in 2014. We use a simple subclass of DeploymentHandler with an overridden script_directory
and storage class. We just call the schemas' upgrade methods manually.
RE: this issue, we don't ever use deploy
since our install base predates our use of DH.
This seems wonky because if I deploy a version I should be on that version - but I also understand that deploy is handled directly by the
HandlesDeploy
. But I'm working with more than one schema, so if I useinstall
again it dies.I feel like I want to call this an issue but my only real problem is that it's odd that the user has to know to deploy and then manually add the version, where it would seem sensible that a deployment would be a procedure that adds the version for you.
Seems like one of three things would be nice:
deploy
when weinstall
(a la #50) but that might break a bunch of stuffdeploy
so it adds the versioninstall
if version storage is already installed, but just skip__VERSION