Currently, while using doctrine migration, FK names are dechex(crc32()) encoded column names.
This is a problem when, I want to start using Doctrine migration for my existing Symfony + Doctrine application, which has really huge DB.
And Index names are also HEX-encoded names.
The problem is, we really don't want to rename all our current ones to hex'y names, because tables are huge.
Need suggestions.
Related
Can anyone explain what's the conceptual difference between #UniqueEntity validator, #UniqueConstraint table annotation and unique=true option of #Column annotation.
I understand that #UniqueConstraint adds UNIQUE index on database level and #UniqueEntity validates on ORM level. So what option shall I use, or do I use all of them?
#UniqueConstraint and unique=true are part of Doctrine and do similar thing.
When you set unique=true on a particular column, then Doctrine will create a unique key on this column physically in database.
#UniqueConstraint can be used to create a unique key in database on multiple columns (complex unique key). But if you pass a single column, then the result will be exactly the same as using unique=true on that field.
#UniqueEntity on the other hand is not a part of Doctrine, but it's a part of Symfony framework. While options above are used by Doctrine to generate proper schema, this one is just a validator used usually by Symfony Form Component at time of submitting the form.
So to answer your final question - yes, you usually should use both #UniqueEntity and one of #UniqueConstraint or unique=true.
As stated in documentation, #UniqueConstraint annotation is used for creation of unique constraint on multiple columns, when unique=true is used for unique constraint on one column.
UniqueEntityValidator exists to show friendly error message and unique database constraint's purpose is to make sure you don't store duplicate data.
So the answer to your question is like this - you should use both database constraint and #UniqueValidator.
I use Symfony2 and Doctrine ORM. I have table "articleType" where I keep all possible article types. I need insert several values to that table only once, when table is created. My question is how and where I should do that? Because I just can't insert that values in controller with every request to that controller right? Maybe I should write down manually that inserts in Doctrine migration class?
It depends, but most of the time Doctrine Migrations are the way to go. Each migration is supposed to be applied just once and that's exactly what you need.
One of the database view I am trying to import using entity framework contains only two columns, one is an integer type of column and another one is an aggregate function. I am getting the following error.
The table/view does not have a primary key defined and no valid primary key could be inferred. This table/view has been excluded. To use the entity, you will need to review your schema, add the correct keys, and uncomment it.
I understand it is a known scenario and it can be fixed by either including a Key column in the view or modifying the edmx file manually.
I just wanted to know if there is some other solution other than the above two? I do not want to include an additional column in my query and making changes in edmx is not feasible as DB changes are very frequent and the edmx will be overwritten every time I update from db.
You can mark both properties as entity key directly in the designer but you must ensure that the composite value of these two properties will be always unique. If you cannot ensure that you must add another unique column anyway or you may have some other problems when working with such entity set.
I have a table where I store relations between two other table with a float indicating relevance between the two rows. I have unique key on the two reference columns. The problem is, that I have to rebuild it regularly, which is kinda lengthy. So, I can't just truncate the table while I'm doing so, but I can't insert the relevance for the same row while they would be duplicates either. That's why I thought it would be great to save the current timestamp to a variable, persist the relations with REPLACE INTO instead of INSERT INTO and then remove everything created before the saved timestamp. However, I couldn't find out how. Any idea? I'm using Doctrine 2.2.0-DEV and Symfony 2.1.0-DEV.
Doctrine 2 doesn't support INSERT REPLACE or UPSERT, sorry.
i have two tables
asset employee
assetid-pk empid-pk
empid-fk
now, i have a form to populate the asset table but it cant because of the foreign key constraint..
what to do?
thx
Tk
Foreign keys are created for a good reason - to prevent orphan rows at a minimum. Create the corresponding parent and then use the appropriate value as the foreign key value on the child table.
You should think about this update as a series of SQL statements, not just one statement. You'll process the statements in order of dependency, see example.
Asset
PK AssetID
AssetName
FK EmployeeID
etc...
Employee
PK EmployeeID
EmployeeName
etc...
If you want to "add" a new asset, you'll first need to know which employee it will be assigned to. If it will be assigned to a new employee, you'll need to add them first.
Here is an example of adding a asset named 'BOOK' for a new employee named 'Zach'.
DECLARE #EmployeeFK AS INT;
INSERT (EmployeeName) VALUES ('Zach') INTO EMPLOYEE;
SELECT #EmployeeFK = ##IDENTITY;
INSERT (AssetName, EmployeeID) VALUES ('BOOK',#EmployeeFK) INTO ASSET;
The important thing to notice above, is that we grab the new identity (aka: EmployeeID) assigned to 'Zach', so we can use it when we add the new asset.
If I understand you correctly, are you trying to build the data graph locally before persisting to the data? That is, create the parent and child records within the application and persist it all at once?
There are a couple approaches to this. One approach people take is to use GUIDs as the unique identifiers for the data. That way you don't need to get the next ID from the database, you can just create the graph locally and persist the whole thing. There's been a debate on this approach between software and database for a long time, because while it makes a lot of sense in many ways (hit the database less often, maintain relationships before persisting, uniquely identify data across systems) it turns out to be a significant resource hit on the database.
Another approach is to use an ORM that will handle the persistence mapping for you. Something like NHibernate, for example. You would create your parent object and the child objects would just be properties on that. They wouldn't have any concept of foreign keys and IDs and such, they'd just be objects in code related by being set as properties on each other (such as a "blog post" object with a generic collection of "comment" objects, etc.). This graph would be handed off to the ORM which would use its knowledge of the mapping between the objects and the persistence to send it off to the database in the correct order, perhaps giving back the same object but with ID numbers populated.
Or is this not what you're asking? It's a little unclear, to be honest.