I have read several posts where they relate that the case sensitive of postgres is activated automatically, when creating tables or fields with capital letters.
I also read some that relate the use of quotation marks.
However, my bank does not have any capital letters or tables.
They also don't have names in quotes.
I'm using Postgres 9.2 and Entity Framework, and I get this error:
Npgsql.PostgresException (0x80004005): 42P01: relation "Usuario" does
not exist
My column is called 'usuario'
I did a test using a DataAnnotation [Table (name = 'user')] and in this case the search for the right one. However I cannot put annotations in all classes / attributes.
The same system, classes / attributes, work normally with a MySQL database.
How can I configure Postgres?
You can set the EF naming convention using UseSnakeCaseNamingConvention. Or if you want to import table definitions from your existing tables to EF, you can
dotnet ef dbcontext scaffold "Host=my_host;Database=my_db;Username=my_user;Password=my_pw" Npgsql.EntityFrameworkCore.PostgreSQL
You might also consider upgrading your PostgreSQL version, 9.2 is not in support any more. That doesn't affect the case problem in naming.
Related
I want to realize two tables, table one has OnToMany and Table two is ManyToOne (so we have a 1 : N relation). Solution: Avoid reserved words.
Looks like your JPA provider does not automatically quote SQL reserved words for you (ORDER) and so the RDBMS is objecting to the SQL thrown at it.
If that is the case (easily checked, can you do a simple query with no WHERE clause?) then you'll have to set the table name as 'ORDER', or change its name to a non-keyword, or use a JPA provider that does auto-quote such things for you (e.g DataNucleus JPA).
When updating schema, doctrine always drops and add constraints. I think, it is something wrong...
php app/console doctrine:schema:update --force
Updating database schema...
Database schema updated successfully! "112" queries were executed
php app/console doctrine:schema:update --dump-sql
ALTER TABLE table.managers DROP CONSTRAINT FK_677E81B7A76ED395;
ALTER TABLE table.managers ADD CONSTRAINT FK_677E81B7A76ED395 FOREIGN KEY (user_id) REFERENCES table."user" (id) NOT DEFERRABLE INITIALLY IMMEDIATE;
...
php app/console doctrine:schema:validate
[Mapping] OK - The mapping files are correct.
[Database] FAIL - The database schema is not in sync with the current mapping file.
How can this may be fixed?
After some digging into doctrine update schema methods, I've finally found an issue. The problem was with table names - "table.order" and "table.user". When doctrine makes diff, this names become non equal, because of internal escaping (?). So, "user" != user, and foreign keys to those tables (order, user) always recreating.
Solution #1 - just rename tables to avoid name matching with postgresql keywords, like my_user, my_order.
Solution #2 - manually escape table names. This not worked for me, tried many different escaping ways.
I've applied solution #1 and now I see:
Nothing to update - your database is already in sync with the current
entity metadata
I have had the same issue on Postgres with a uniqueConstraint with a where clause.
* #ORM\Table(name="avatar",
* uniqueConstraints={
* #ORM\UniqueConstraint(name="const_name", columns={"id_user", "status"}, options={"where": "(status = 'pending')"})
Doctrine is comparing schemas from metadata and new generated schema, during indexes comparation where clauses are not matching.
string(34) "((status)::text = 'pending'::text)"
string(20) "(status = 'pending')"
You just have to change you where clause to match by
((avatar)::text = 'pending'::text)
PS: My issue was with Postgres database
I hope this will help someone.
I have come across this several times and it's because the php object was changed a few times and still does not match the mapping to the database. Basically a reboot will fix the issue but it can be ugly to implement.
If you drop the constraint in the database and php objects (remove the doctrine2 mappings), then update schema and confirm that nothing needs to be updated. Then add the doctrine mapping back to the php, update the schema using --dump-sql and review the changes that are shown. Confirm that this is exactly what you want and execute the update query. Now updating the schema should not show that anything else needs to be updated.
I have a .NET 4.0 application that uses Entity Framework 4 that connects to a MS SQL 2008 database. The naming convention used is for example table "Clients", fields : "Id", "Id_Order". Now I need to switch from SQL Server to Oracle Server, so I migrated the MS SQL database to oracle database, but the problem is that all the table names and column names are uppercased, so by generating the edmx for oracle(using ODAC), I will have to change in code from "Clients" to "CLIENTS", "Id" to "ID", "Id_Client" to "ID_CLIENT", and it's a lot to change.
The migration was done using the built-in migration tool from Oracle SQL Developer 3.1.07.
A snippet from the generated script:
CREATE TABLE Clients (
I have read that in order to create case-sensitive identifiers you must use double quotes.
So I think the script should be something like this:
CREATE TABLE "Clients" (
Does anyone know a migration tool that perserves names case or at least a general option that I can switch on in the script ?
Why do you need to change the code? The whole point of Oracle being case-insensitive is that you can refer to the table as clients, Clients, CLIENTS, or even clIeNtS, and it will work.
You only use the double-quotes if you want case-sensitivity for some reason, but unless you have table names that are the same apart from case (shudder), you shouldn't need it.
Ì am currently working on a ASP NET MVC project. We use Entity Framework and follow the Database First approach. The database already exists.
The database has been created using the convention, that every table has a specified single primary key, even if it is a junction table.
Example :
Table User :
UserId (PK);
Username
Table UserRole :
UserRoleId (PK);
UserId (FK);
RoleId (FK)
Table Role :
RoleId (PK);
Rolename
As said, the database already exists and this convention is not discussable.
When I want to create an Entity Data Model in Visual Studio, I also have three Entities. But it would only make sense to have two Entities: User and Role. The UserRole Entity makes no sense.
Is there any possibility I can influence the way that Entity Framework maps my tables, so I can get rid of those relational (useless) entities?
Is there any possibility I can influence the way that Entity Framework
maps my tables, so I can get rid of those relational (useless)
entities?
No, you cannot force EF designer to do that. When using automatic tools you will always end with junction table mapped as a separate entity because it is not considered as junction table any more - it has special data (a separate key) which gives this entity new possibilities (for example relation between two entities can exist multiple times which is not possible with normal junction table).
The only way to avoid this is abandon tooling support and use either code mapping or manually write EDMX file and don't tell EF about that additional key. Instead let EF believe that there are only those two FKs forming composite PK as expected from junction table. Obviously if your database requires those special possibilities allowed by separate PK you cannot do this.
I am using JOINED inheritance strategy with EclipseLink JPA implementation. I have noticed that EclipseLink is adding discriminator column, named by default DTYPE, to the database schema. I understand, that discriminator is needed for one table inheritance strategy, but why for JOINED strategy?
EclipseLink needs this column because I've got errors after removing it. Is this column added for performance reasons, etc? I am not particularly happy about that since from the point of view of database schema this column is just unnecessary clutter.
Hibernate based JPA does not do anything similar.
From Joined Table Inheritance:
In the joined table inheritance, each
class shares data from the root table.
In addition, each subclass defines its
own table that adds its extended
state. The following example shows two
tables, PROJECT and L_PROJECT, as well
as two classes, Project and
LargeProject:
...
The discriminator column is what determines the type and thus what joined table to use so you need a discriminator column in the parent table.