propel init reverse engineering wrong schema?

[legecha]

I'm expecting this to be down to my environment but I can't figure out why it's happening. After successfully running through propel init I am left with the following:

[leonard@ombrelle returns]$ ls -al
total 52
drwxrwxr-x.  4 leonard developers  4096 May 26 13:12 .
drwxrwxr-x. 18 leonard developers  4096 May 26 13:13 ..
-rw-r--r--.  1 leonard developers    63 May 26 12:46 composer.json
-rw-r--r--.  1 leonard developers 20133 May 26 12:47 composer.lock
drwxrwxr-x.  7 leonard developers  4096 May 17 14:58 .git
lrwxrwxrwx.  1 leonard developers    17 May 26 12:48 propel -> vendor/bin/propel
-rw-rw-rw-.  1 leonard developers   505 May 26 13:00 propel.php
-rw-rw-rw-.  1 leonard developers  1488 May 26 13:00 propel.php.dist
-rw-rw-rw-.  1 leonard developers  2280 May 26 13:00 schema.xml
drwxr-xr-x.  7 leonard developers  4096 May 26 12:47 vendor

propel.php is exactly as you'd expect - the correct credentials. schema.xml, however, shows the definition for a different database! I wondered if maybe propel was running from somewhere else?

[leonard@ombrelle returns]$ whereis propel
propel:
[leonard@ombrelle returns]$ type -a propel
propel is a function
propel ()
{
    ./propel "$@"
}

This seems OK. The schema it has details for is actually for a project located at /var/www/subdomains/commitr and has it's own unique credentials.

The values in propel.php are for user le_returns, and to confirm:

mysql> SHOW GRANTS FOR 'le_returns'@'localhost';
+-------------------------------------------------------------------------------------------------------------------+
| Grants for le_returns@localhost                                                                                   |
+-------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'le_returns'@'localhost' IDENTIFIED BY PASSWORD '*AAAAAAAAAAAAAAAAAAAAAAAAAA' |
| GRANT ALL PRIVILEGES ON `leonard_returns`.* TO 'le_returns'@'localhost'                                           |
+-------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
mysql> SHOW TABLES IN `leonard_returns`;
+---------------------------+
| Tables_in_leonard_returns |
+---------------------------+
| email                     |
| fault                     |
| note                      |
| priority                  |
| product                   |
| return                    |
| status                    |
| type                      |
+---------------------------+
8 rows in set (0.00 sec)

But this is the output in schema.xml in the same folder:

<?xml version="1.0" encoding="utf-8"?>
<database name="default" defaultIdMethod="native" defaultPhpNamingMethod="underscore">
  <table name="query" idMethod="native" phpName="Query">
...
  <table name="repository" idMethod="native" phpName="Repository">
...
  <table name="user" idMethod="native" phpName="User">
</database>

Hence:

mysql> SHOW TABLES IN `commitr`;
+-------------------+
| Tables_in_commitr |
+-------------------+
| query             |
| repository        |
| user              |
+-------------------+
3 rows in set (0.00 sec)

Finally:

[leonard@ombrelle returns]$ echo $PATH
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/leonard/bin

None of these locations exist or contain propel.

Any ideas why propel is working on the wrong database?

[marcj]

Can you please show propel.php? The DSN is important.

[legecha]

'dsn' => 'mysql:host=localhost;port=3306;dbname=leonard_returns',

[marcj]

Can you please try using the database:reverse command? If this is working fine, then init is the issue.

[legecha]

Thanks @marcj, this led me to looking at the init command. Long story short, I found that in /tmp there already exists a file called schema.xml owned by another user, and I can confirm the content of this file matches what I found in my own schema.xml.

I removed the file and ran init again in its entirety and it worked as expected.

Is it worth having some form of check in there to see if it can be written to and/or clean up afterwards?

[dereuromark]

Is someone able to make a PR here with suggested changes?