Refactor code to only optionally require DBIC

[frioux]

Currently the code is very DBIC centric. You must connect with a DBIC schema at the very least. We should factor out the "runner" part of the DM so that people can slot in whatever they want. So maybe a spartan user will only support .sql files run with a raw $dbh, or maybe someone special wants to use Rose::DB or DBIDM instead of DBIC for .pl migrations (probably a bad idea unless they have an ::SL replacement, but still.)

[mohawk2]

Is this really a problem?

[frioux]

It's a feature request I've gotten from real users. Using DBIC as the source schema is convenient but hardly essential. Anyway I probably won't do it so if you don't want to feel free to close.

…

-- Sent from a rotary phone rented from Ma Bell

On Fri, Mar 8, 2019, 9:24 PM mohawk2 ***@***.***> wrote: Is this really a problem? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAf4_V4CndK19wCAhgrhw4yScsmminYks5vU0WXgaJpZM4AHV1e> .

[mohawk2]

I'm not opposed. I think it would be necessary to:

• abstract out all the current uses of ->schema into the things that use them
• isolate those into another interface thingy like VersionStorage, maybe DBStorage
• provide an alternative DBStorage that could talk directly to a $dbh, and probably the existing DBIC-orientated way could switch to just using that behind the scenes

[mohawk2]

I am told this includes needing to get the create_ddl_dir out of DBIC.

It would probably be useful to put that into a separate module, which DBIC or a successor could then depend on and use, which would shrink it down.

[frioux]

Why? DBICH doesn't call that

[mohawk2]

Good point - but isn't there all the stuff that ends up calling sql_translator_hook? We'll see when I get to it, though.

[frioux]

yeah but that stuff is "for free" if you are using DBIC; you just won't have it if... you aren't using DBIC

[Altreus]

A while ago I was part of a conversation in which vague lamentations were made about the current structure of the code, and how a 2.0 might be structured differently to allow more exensibility.

If we're considering removing the DBIC from DBICDH, would this be a good opportunity to simply create a new module that doesn't have DBIx::Class in its name, and doesn't contain the design decisions we would like to unmake?

[mohawk2]

I'm open to any specific ideas - you're referring to the install vs deploy discussion? I still want to resolve that.

My feeling is there's no real need to throw the baby out with the bathwater, and we can add possibilities without having to start from scratch.

[frioux]

If anything I think DBICDH is too extensible.