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

Issue with Migrations and PostgreSql's numeric and decimal types #695

Closed
rayrigam opened this issue May 22, 2013 · 6 comments · Fixed by #704
Closed

Issue with Migrations and PostgreSql's numeric and decimal types #695

rayrigam opened this issue May 22, 2013 · 6 comments · Fixed by #704

Comments

@rayrigam
Copy link
Contributor

As initially mentioned at propelorm/PropelBundle#187 (comment) , there is an issue with Propel Migrations and columns having decimal or numeric types, like the "vote_score" column in the schema below:

<table name="book">
    <column name="id" type="INTEGER" primaryKey="true" autoIncrement="true" required="true"/>
    <column name="vote_score" type="DECIMAL" size="4" scale="3" required="true" defaultValue="0.000"/>
</table>

In such a case, running the app/console propel:migration:generate-diff command, after having inserted the table, always generates a diff (even when there are no real changes) with a migration file including:

public function getUpSQL()
    {
        return array (
          'default' => '
            ALTER TABLE "book" ALTER COLUMN "vote_score" TYPE DECIMAL(4,3);
            ALTER TABLE "book" ALTER COLUMN "vote_score" TYPE DECIMAL(4,3);
          ',
        );
    }
public function getDownSQL()
    {
        return array (
          'default' => '
            ALTER TABLE "book" ALTER COLUMN "vote_score" TYPE DECIMAL(262147);
            ALTER TABLE "book" ALTER COLUMN "vote_score" TYPE DECIMAL(262147);
          ',
        );
    }

The migration file with the above functions is generated even after applying the migration with app/console propel:migration:migrate and re-running the generate-diff command. I tried changing the size and scale parameter values to "5" and "4" respectively (as per comments of Francois in http://trac.propelorm.org/ticket/1401 ) but that did not eliminate the problem. As a temporary fix, one can always check the generated diff file and eliminate the above entries. Notice that I'm running Propel with Symfony2.2 and PropelBundle 1.6.9, but the problem seems to be with Propel itself.

@afrosimon
Copy link

I encountered the same problem and can attest to the veracity of the description above. Getting rid of the size parameter in the schema did not help.

@marcj
Copy link
Member

marcj commented Jun 3, 2013

Do you guys have perhaps a fix already for it?

@rayrigam
Copy link
Contributor Author

rayrigam commented Jun 5, 2013

I do not know of a fix. Manually checking the generated diff file and eliminating the redundant commands is necessary for now.

auss pushed a commit to auss/Propel that referenced this issue Jun 12, 2013
Fixes propelorm#695. The "NUMERIC" type is not mapped in the array, so if in line 288 always returned false.
@rayrigam
Copy link
Contributor Author

Good to hear that this issue has been addressed. Although, I have not been able to try it yet because of a somewhat unrelated issue. The fix was introduced in propel 1.7.x-dev, but I cannot get that version through Composer because the typehyntable behavior dev-master requires propel 1.6.* . @willdurand , is it possible to update the Composer requirements of the typehyntable behavior? thanks and best!

@willdurand
Copy link
Contributor

yep

@rayrigam
Copy link
Contributor Author

Thanks! I just tried it and it works!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants