Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Returning file *path* as ->getDatabase() for SQLite #4982

Closed
wants to merge 1 commit into from

Conversation

ThomasLandauer
Copy link
Contributor

Q A
Type improvement
BC Break ?
Fixed issues none

Summary

I'm suggesting to return the file path as "database name" for SQLite (instead of nothing)

Right now, when loading fixtures, the CLI prompt reads:

Careful, database "" will be purged. Do you want to continue? (yes/no)

This is due to LoadDataFixturesDoctrineCommand::execute() at https://github.com/doctrine/DoctrineFixturesBundle/blob/3.4.x/Command/LoadDataFixturesDoctrineCommand.php#L106

I don't know where else Connection::getDatabase() gets called, but I'm figuring that returning the path is always a good idea :-)

The query syntax is taken from https://stackoverflow.com/a/44279467/1668200

I'm suggesting to return the file path instead of the database name for SQLite.

Right now, when loading fixtures, the CLI prompt reads:
> Careful, database "" will be purged. Do you want to continue? (yes/no)
This is due to `LoadDataFixturesDoctrineCommand::execute()` at https://github.com/doctrine/DoctrineFixturesBundle/blob/3.4.x/Command/LoadDataFixturesDoctrineCommand.php#L106

I don't know where else `Connection::getDatabase()` gets called, but I'm figuring that returning the path is always a good idea :-)
@morozov
Copy link
Member

morozov commented Nov 11, 2021

SQLite doesn't support the concept of a database. Instead, we should consider throwing an exception there. See #4963 for more details.

@ThomasLandauer
Copy link
Contributor Author

ThomasLandauer commented Nov 11, 2021

My first question is: Since the fixtures command did work until recently, was there a change here in DBAL or in the fixtures bundle? I couldn't figure anything out in GitHub's history :-(

For the larger topic: The main question I'm seeing is: If somebody is calling Connection::getDatabase(), which information are they looking for? I would say: They want to know where their stuff is being written to! So while I'm seeing your point that semantically this isn't 100% correct: What harm does it do if you just return that path?

@morozov
Copy link
Member

morozov commented Nov 11, 2021

Since the fixtures command did work until recently, was there a change here in DBAL or in the fixtures bundle?

The relevant change in the DBAL was released in 3.0.0 (see #3606 for more details).

What harm does it do if you just return that path?

This behavior wouldn't be portable. Each method has its semantics, and a database has a certain meaning in the DBAL. The SQLite platform doesn't support these semantics, so returning something from this method which is not a database may help solve some cases but become an unpleasant surprise in others.

If a tool wants to display an informational message, it should do so based on the connection configuration.

ThomasLandauer added a commit to ThomasLandauer/DoctrineFixturesBundle that referenced this pull request Nov 11, 2021
Since DBAL 3.0 (see doctrine/migrations#1028), the message currently reads for SQLite:
> Careful, database "" will be purged. Do you want to continue? (yes/no)

Neither @Ocramius (see doctrine/dbal#3606 (comment)) nor me (see doctrine/dbal#4982) succeeded in convincing @morozov to continue returning the file path ;-) So it looks like the fix needs to be done here...

Suggestion: What about adding the platform too? So the message would be:
> Careful, MySQL database "foo" will be purged. Do you want to continue? (yes/no)

`doctrine/migrations` is currently broken too:

> WARNING! You are about to execute a migration in database "<unnamed>" that could result in schema changes and data loss. Are you sure you wish to continue? (yes/no) [yes]:

So when done here, I'm going to submit the same there  (i.e. follow up of doctrine/migrations#1028)
@ThomasLandauer
Copy link
Contributor Author

OK, thanks, so I'm closing here in favor of doctrine/DoctrineFixturesBundle#359 :-)

@ThomasLandauer ThomasLandauer deleted the patch-1 branch November 11, 2021 23:22
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants