now i find a way to rename the table
foreach ($sm->listTableForeignKeys($table->getName()) as $foreignKey)

and then rename.
but it is right that the rows doesnt copy?
or is there a was that i can do it?

else this would be a good feature

Windows & Linux

Can you paste an exception trace? I see that filtering is applied to sequences, but your description seems to indicate this happens due to an SQL query much earlier?

Dear Benjamin,

the context is when using migrations. Positive regexp expressions do not limit the migration to a single schema. eg ^schemaname.$
Instead, all sequences on the current database are returned.
When trying to limit a migration to a single schema consecutively this doesn't work.
We are using a per-schema connection, so this results in a lot of hassle for us.

It seems the only missing piece is the implementation of the getGuidExpression method in the PostgreSqlPlatform class.

Details on generating UUIDs from postgres can be found here:

http://www.postgresql.org/docs/current/static/uuid-ossp.html

Things that would need to be addressed:

1) It requires the uuid-ossp module to be installed in the database. Solve with documentation or ...?

2) There isn't just one function. Just pick one or make it configurable with a sane default?

I have implemented this for my own project, using what I think is a sane default:

public function getGuidExpression()

The other issue I think that needs addressing is that the extension must be loaded into the current database upon creation. Either this is a deal-breaker right here (relying on a PGSQL plugin that's not available by default)

OR

If not, maybe schema:update/create needs to check for whether postgresql is being used, whether there is a guid type/generator being used in an entity, and then either execute CREATE EXTENSION uuid-ossp;, and failing that return an exception that informs the user that uuid-ossp must be available as an extension before GUID generation can be used in entities.

Can someone explain to me please the position on this currently? Is it not ok to rely on non-core/standard functionality?

Is there any sort of decision on this item? I was trying to use UUID with Postgres and finally got it to work by adding

public function getGuidExpression()

and went to submit a patch, then found this ticket and see that it's the exact same solution that Ross Cousens submitted above. I'd really like to not maintain my own fork of the repository just to have this change in place, and it seems like a reasonable fix (barring the uuid-ossp extension not being a Postgres default extension). Can we get this in there so it's available, and worry about the issue of informing the user about the extension at a later point?

Or is there an easy way that anyone knows that I can add the function to my own class (in a Symfony2 project) that would extend PostgreSqlPlatform.php and add the function, without the need for me to fork Doctrine and add it on my own?

Thanks,
--mark

Pull request submitted

https://github.com/doctrine/dbal/pull/312

I hope this gets accepted but I fear it won't.

The original complaint against implementing GUID for the PostgreSQL platform driver was because a) it required a separate extension to be enabled on the server itself b) and there were a number of GUID generation functions available.

To use anything but v4 would be asinine unless some external constraint was forcing you to use the older generation algorithms, so I think argument b is mostly moot. Argument a can easily be solved with documentation, programmatically as well (would require more work) or just left as is because the error back from postgresql is very verbose. Cannot find function uuid_generate_v4. Google it, see that extension is required, see that it's available in PostgreSQL contrib packages, enable it, and voila it works.

Agreed, and I think that having SOMETHING that is usable (and has a very clear message that you need to install an extension) is better than nothing. The implementation can be expanded later to cover the extension not existing, or using something other than v4, etc. But this should be good enough for most people and it seems silly not to have, or at least not have a way to override and provide it.

I was looking at the Symfony configs to see if there was a way to define my own platform class that could then just extend the current PostgreSqlPlatform class and add a the function, but that doesn't seem to be doable (or I just missed it)

I just saw that this got merged into master. As soon as this hits 2.3* I can do away with the manual UUID generation for id's that we're currently doing

Thanks much Benjamin!

Yay, I am happy that this has been accepted and will make it through to next release. Thank you Mark/Benjamin!

postgresql

Doesn't only happen on Enums. I don't use any enums and I have this problem. I use a couple of geo (postGIS) fields (point, linestring, polygon) as well as array fields, so either or all of those might be causing it, too.

We did some changes for PostgreSQL column diffs lately, can you verify this bug still exists on the 2.3 Branch of DBAL?

I'm running this on Symfony2 with this composer.json config:

"doctrine/orm": "2.3.*",
"doctrine/doctrine-bundle": ">=2.1",

and I'm still getting this issue today.

IIS 7.5, MS-SQL-Server 2005, PHP 5.4.0

Are you sure you were using the 2.2.2 version of the ORM? Can you try to reproduce this with the latest master?

Ubuntu 12.04 with MySQL 5.5 and PHP 5.4

Did you specify an index name in the indexes property for your entity in your PHP file? In this case, you should have something like:

indexes={@Index(name="IDX_ADDRESS_CITY", columns={"city_id"})}

That should result in the correct SQL being generated. If I modify the above to:

indexes={@Index(columns={"city_id"})}

I also get a migration that has SQL with an auto-generated index name.

Yes I did specify a name, as you can see:

uniqueConstraints:
    UNIQUE_STATE_SLUG:
        columns: slug
indexes:
    IDX_USER_ADDRESS:
        columns: address_id

I don't try do to it using annotations because I choose do use yaml to describe my entities. I will take a look on the source code to see if I can fix it and send a PR.

I already sent this patch to Guilherme Blanco, but I guess he doesn't have time to take a look on it.

I guess my solution it's not ideal, but it solve the problem and can be a base to make a better solution.

Diego Oliveira the fix doesn't seem too nice with the additional boolean flag.

I would rather like to fix the root cause instead of adding this solution.

The issue is tricky, because we cannot just move the index definitions above, they will need the columns, however that directly generates the index in the schema tool. Maybe if the gather join column methods would check if they can add an index already it would work.