Separate creating the DB schema from the engine creation

[chrisburr]

When running in production we don't want to be filling the DB schema everytime the engine is created.

This PR:

• Adds a new classmethod available_implementations to BaseDB that retrieves available implementations for a given database name.
• Adds a __main__ module to diracx.db such that the databases can be initialised with something like python -m diracx.db init-sql

[chaen]

I think it's worth adding a parameter to specify a DB already

[chrisburr]

At the moment it's implicitly done by controlling which environment variables are set. As we know we want to use something like Alembic I wasn't sure it was worth making this more complex until we know how best to integrate it?

[chaen]

I was hesitating yesterday before writing the comment exactly because of Alambic. However, it does mean that before we support for real the first endpoints (i.e. we can run a given functionality with diracx only, we need to have Alambic strategy sorted out). I am fine with this though, but we should have it on the road map

[chrisburr]

I thought Alambic was already on the roadmap.

it does mean that before we support for real the first endpoints (i.e. we can run a given functionality with diracx only, we need to have Alambic strategy sorted out)

Why is this the case?

[chaen]

I thought Alambic was already on the roadmap.

Of course it is, the questions is just where to place it :-)

Why is this the case?

Because if we start with an alternative handcooked solution, we take the usual risk of not investing the effort of doing things properly

[chrisburr]

I don't see how adding a CLI parameter to specify the DB makes the sitution any better. It just makes it more likely it gets push off to "later".

[chaen]

That is exactly my point :-) So we agree, it just means that we need to start looking at Alambic earlier than I had though

[chrisburr]

Agreed #88