I'm developing a ws with Symfony2 / Doctrine2, and I'm trying to hook into Doctrine2 lifecycle and trigger a function before any SELECT action - but without any luck. Basically, i'd like to dynamically manipulate the selection queries adding limit/offset when certain parameters are found in the request, but it seems that Doctrine2 hooks concern only insert, delete and update actions. Am i missing something?
Thanks.
U have to use Doctrine Filter
Doctrine 2.2 features a filter system that allows the developer to add SQL to the conditional clauses of queries, regardless the place where the SQL is generated (e.g. from a DQL query, or by loading associated entities).
A way to deal with this would be to register a custom event that is dispatched before a select. You have already referenced the source that shows examples of how to do it.
Related
There does not seem to be proper documentation available on how to configure and use database views with the doctrine migrations bundle.
One probably is not able to map SQL statements which will end up creating/updating a database view (from the sql given somewhere) when migrations:diff and migrations:migrate are run.
If an entity is mapped to a database view with the #table(name="view_name") markup, it ends up causing an error / new table being attempted, instead of understanding that its a database view being used.
Is there a solution? Am I missing something?
I'm not sure that doctrine can get out of the box views. For all I know, you'll have to cheat.
Or:
I think you have to write the migration script yourself.You can generate an empty one and then write the create-statements into it.
In the repository you integrate native sql. The result you map to your entity or DTO.
https://www.doctrine-project.org/projects/doctrine-orm/en/2.7/reference/native-sql.html
The tutorial of zend framework show that I can use Zend\Db\ResultSet\HydratingResultSet to return a model object using the dbAdapter ,select query and a model prototype. But in most case writing the website code I use multi-table query and the hydrator can not fix this problem but just a single table query. How should I deal with this kind of problem.
hydrator doc
And this problem can also happen when encounting the pagination which also only take one prototype.
paginator doc
Depending on the query, you might need a custom ResultSet that knows how to deal with the multi-row potential of a multi table query, and mapping that dataset appropriately.
Additionally, if you find yourself getting into very advanced object relationships with Zend\Db, that might be the time to start considering Doctrine2 (or a similar ORM).
I have an entity which uses a table called software. In the UI of the app I'm developing, all of the entries in software are useful to users in lists or dropdowns in forms. Unfortunately, the database automatically inherits another table called software_dynamic when selecting from software.
This makes it so the UI has approximately 15,000 software entries it doesn't need when using the entity in the Symfony FormBuilder, for example. Another example would be something like this:
$doctrine->getManager->getRepository('Software')->findAll();
Returns all of the extraneous entries the users don't want to see as well.
What I need to do is get Doctrine to run a query like select * from only software. I've attempted to do this through the query_builder option in the FormBuilder, but I could only find a way to return an array of the results I wanted - Not an instance of QueryBuilder like the FormBuilder requires.
My concern is that my only option here is to manually query for the software, then pass that into the form as an option. This isn't ideal, but it's starting to seem like the only option.. I'm just hoping someone out there knows how to tell a Doctrine entity not to inherit from other tables, essentially using the only statement in SQL.
I have no way to discriminate between software and software_dynamic through Doctrine; they're identical tables but one is manually populated from a CRUD (The ones the users want to see) and the other is populated automatically through an API (Only useful to the backend).
Have you accidentally set the fetch mode to EAGER loading? This would indeed cause the opposite effect of what you desire.
However, when you do require eager loading in some cases:
$query = $em->createQuery("SELECT e FROM MyProject\Entity e");
$query->setFetchMode("MyProject\AssociatedEntity", "field", "EAGER");
$query->execute();
I am attempting to encrypt certain database fields by adding a call to mysql AES_ENCRYPT (and AES_DECRYPT) using Doctrine DQL Hooks.
for SQL SELECT's I have a preDqlSelect() in my Doctrine_Record_Listener class, which goes through each parameter in the select fields, and adds a AES_DECRYPT() for encrypted fields.
But, it looks like calling save() on a doctrine model class only calls the preSave() listener and does not call any of the preDql* listeners.
Can anyone suggest a way of getting this to work or a better way of doing this?
Thanks
In order for these dql callbacks to be checked, you must explicitly turn them on. Because this adds a small amount of overhead for each query, it is off by default
$manager->setAttribute(Doctrine_Core::ATTR_USE_DQL_CALLBACKS, true);
Doctrine 1.2 Event listeners
nHibernate has a great feature called filters, so i can create criterias globally for my applications. I'm starting a project in PHP and i need to use an ORM, i'd like to know if Doctrine has a similar feature to manage query conditions.
thanks
I think what you are looking for are Doctrine Query Hooks.
There a numerous hooks for preUpdate, preSave, preCreate, postCreate, postUpdate, postSave, preSelect, and so on and so forth.
Hope this helps.
Doctrine 2.2 features a filter system that allows the developer to add SQL to the conditional clauses of queries, regardless the place where the SQL is generated (e.g. from a DQL query, or by loading associated entities).
The filter functionality works on SQL level. Whether a SQL query is generated in a Persister, during lazy loading, in extra lazy collections or from DQL. Each time the system iterates over all the enabled filters, adding a new SQL part as a filter returns.
By adding SQL to the conditional clauses of queries, the filter system filters out rows belonging to the entities at the level of the SQL result set. This means that the filtered entities are never hydrated (which can be expensive).