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.
Related
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.
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 am using Doctrine ORM and I want to insert some rows when I update the current schema.
Which is the best way to achieve that?
You can use DoctrineFixturesBundle for load initial or test data
Fixtures are used to load a controlled set of data into a database.
My Querybuilder statement looks like this:
$qb->from('models\Order', o');
$qb->innerJoin('o.fStatus', 'fs');
$qb->select('COUNT(o.id), PARTIAL fs.{name, id}');
If I run this I get the error
SELECT COUNT(o.id),': Error: Cannot select entity through identification variables without choosing at least one root entity alias.
However, if I change my select statement to either of these:
$qb->select('PARTIAL o.{id}, PARTIAL fs.{name, id}');
$qb->select('COUNT(o.id), fs.name, fs.id');
The query will run.
Why can I not select from the root entity and also a partial object that has been joined to it?
Doctrine gives a bit of explanation in their documentation:
A common mistake for beginners is to mistake DQL for being just some form of SQL and therefore trying to use table names and column names or join arbitrary tables together in a query. You need to think about DQL as a query language for your object model, not for your relational schema.
When you select using DQL or the QueryBuilder, it is traditionally expecting you to select the root entity (the one in your FROM clause), or some combination of columns/aggregates (COUNT, SUM, etc.). When you select a partial object from a joined table but don't select the root entity, Doctrine doesn't know how to hydrate - what if there is a one-to-many/many-to-one, how does it return the data? It won't make those assumptions.
Doctrine by default does not allow partial objects. It seems like you would be better off just returning columns for your query since that's really what you're looking for in that case.
Others have worked around the issue using the WITH clause - see Doctrine query distinct related entity.
Anybody know if it's possible to;
Dynamically create LINQ classes for tables/columns that change regularly?
If that creation can be used in DynamicData.
A web app we are developing creates tables and columns in SQL. We want to edit these tables in DynamicData.
Thoughts?
Depending on what type of Database you are running, but you could always have a linq statement that queries the systems schema table and have it return the tables and columns. Then could use what you return and then use another linq query to break out the information from each table.
I used sqlmetal.exe from the SDK, it's a winner.