deploy doesn't set the version but install and upgrade do

[Altreus]

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 use install 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:

• Don't deploy when we install (a la deploy should not run __VERSION #50) but that might break a bunch of stuff
• Wrap deploy so it adds the version
• Don't die on install if version storage is already installed, but just skip __VERSION

[Altreus]

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

[frioux]

Why are you calling deploy instead of install?

[mohawk2]

@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.

[Altreus]

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.

[mohawk2]

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.

[frioux]

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.

[mohawk2]

@frioux That IS interesting - did the different schemas have independent versions, or was it one version = all the schemas?

[frioux]

Different versions; I'm not sure how they could be different schemas otherwise :)

[wesQ3]

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.

[mohawk2]

@wesQ3 Are you using DBICDH?

[wesQ3]

@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.