I asked a related question previously on this forum. This question outlines the steps I have taken, different things I have tried and errors I have encountered. It might help someone.
Considering a mapping to a structure that involves a link table, it seems to me there is a quirk with Code First, Link Tables and TPH or perhaps just a lack of transparency.
I created a derived class with a [Table("")] attribute to map objects to the following sort of table structures:
(Case 1) Employees -> Attributes -> AttributeTypes
(Case 2) Employees -> EmployeeAttributeLink -> Attributes -> AttributeTypes
In the former case i achieved the results i wanted for TPH querying and saving. (I used data annotation attributes along with fluent api to map the derived classes to the correct discriminator id column).
However, in the second case I got this error:
'The entity types A and B cannot share table B because they are not in the same type hierarchy [OR] do not have a valid one to one foreign key relationship with matching primary keys between them. Need to have a 1-1 correspondence'
When I looked at the names of the tables that it was trying to map types to I could see it was confused. However I could not figure out what I was doing wrong as I had used the correct table mapping attribute above the inheriting classes (I didn't define all the sub types that could come from the discriminator - does that matter?).
I introduced some FK attributes trying to address the second part of the [OR] in the error message. This led me to new problems i.e. unable to determine principal/dependant... Then I tried to use the [InverseProperty] attributes... And then I started pulling my hair out.
Now, rolling back and removing the attributes, I decided not to rely on [Table("")] attribute and map the type to the table using the fluent api. This seems to work.
My question is: Why is it that the behaviour of the [Table("") ] attribute and the ToTable function on the fluent API behave differently? I would have thought they are interchangeable
Thanks
Related
I'm creating a data entity with multiple tables and I'm getting duplicate results. Because of the nature of the duplicates, I thought an easy solution would be to add the relevant fields to the Group By section in the primary datasource. However, when I run the entity as a data project in the DMF, I'm getting the following error:
Has anybody run into this before and how do I resolve it? I've tried adding the RecId to the group by (even though it shouldn't even be in the select list as it is not in the field list for the entity). I have noticed that adding fields to the Group By section changes the view in SQL and removes all of the RecId#2, Partitian#2 etc. fields. Does the Group By section even work or is it a broken "feature"?
The entity works perfectly (other than with duplicate results of course) when I remove all fields from the group by section.
UPDATE: From what I can find online, the group by functionality doesn't work. I'll update this question if somebody finds an answer. I am lucky this was an XML export, so I was able to use a XSLT file in the transformations under data entity mapping to remove duplicates.
Iterations of this question have been asked in the past, but this presents unique challenges as it combines some of the issues in one larger problem.
I have an entity(User) that is used as the user class in my application, then I have another entity (UserExtra), in a one-to-one relationship with the user entity, UserExtra's id is the same as User. The foreign key is the same as the primary key.
When the user object is loaded (say by $this->getUser() or by {{ app.user }}, the UserExtra data is also loaded through a join. The whole point of having two entities is so I don't have to load all the data at once.
I even tried defining a custom UserLoaderInterface/UserProviderInterface Repository for User, making sure that refreshUser and loadUserByUsername would only load the User data (I'd like for the UserExtra data to sit in a proxy unless I explicitly need it) but when Doctrine goes to Hydrate the object, it issues an extra query to load the UserExtra data, thereby skipping the Proxy status.
Is there a way out of this?
there are many solution for your issue:
1) Change the owning side and inverse side http://developer.happyr.com/choose-owning-side-in-onetoone-relation - I don't think that's right from a DB design perspective every time.
2) In functions like find, findAll, etc, the inverse side in OneToOne is joined automatically (it's always like fetch EAGER). But in DQL, it's not working like fetch EAGER and that costs the additional queries. Possible solution is every time to join with the inverse entity
3) If an alternative result format (i.e. getArrayResult()) is sufficient for some use-cases, that could also avoid this problem.
4) Change inverse side to be OneToMany - just looks wrong, maybe could be a temporary workaround.
5) Force partial objects. No additional queries but also no lazy-loading: $query->setHint (Query::HINT_FORCE_PARTIAL_LOAD, true) - seams to me the only possible solution, but not without a price:
Partial Objects are a little bit risky, because your entity behavior is not normal. For example if you not specify in ->select() all associations that you will user you can have an error because your object will not be full, all not specifically selected associations will be null
6) Not mapping the inverse bi-directional OneToOne association and either use an explicit service or a more active record approach - https://github.com/doctrine/doctrine2/pull/970#issuecomment-38383961 - And it looks like Doctrine closed the issue
this question may help you : one to one relation load
I need to create a fairly complex rule in Drupal - I am willing to use either code or the interface to do so.
I am more familiar with the interface, however, as opposed to the Rules API.
Anyway, the rule will be as follows:
It will happen based on a form submission from entityforms (which is one entity). It will take the checkbox value of a field (not just the true or false, but rather the value submitted when a value is true or false). It will convert this number to an integer.
At this point things get interesting - I want to create a new entity of registrations (a different entity), which as far as I can tell, means I'll have to bring a registration into scope. I also need to bring node (and not just node: type and other data selectors, but specifically node) into scope, because the next step requires it.
So at this point, I should have three entities loaded into scope:
entityforms
registration
node
I believe the best way to bring registration into scope would be entity is of type? The documentation page says that content of type should be appropriate - but that seems like it might be related to the specific use case of the example - not in my more complex example where registration isn't the first entity dealt with, but rather a second.
https://drupal.org/node/1463042
So anyway, if all three of these entities is called in correctly, the ultimate result should be the following:
Value from boolean field (not the straight 1 or 0, but whatever the value to be submitted is switched to) from the entityform is converted to an integer, and inserted where entity host ID is required. In the section where host entity type is the value should be node.
I am also open to alternative suggestions if this seems overly complex or poorly architected.
The Host Entity Type cannot be of Entityform? Why be a Node since a Registration can be attached to any entity? Then you will get the id of the Entityform as also as any other fields from that entity type instead of Node. Next steps are the same.
I'm running into a problem with the Symfony2 Security system, particularly when trying to load Roles from a database. Before going further, I am aware of FOSUserBundle, but at the moment, in an effort to better understand the Symfony2 framework, I want to try and make my bundle work using Symfony2 components only. TL;DR -> please don't tell me to just use the FOSUserBundle. :-)
I have 3 entities configured in my bundle, Accounts, AccountsRoles, and AccountsRepository.
src\RedK\Core\IndexBundle\Entity\Accounts.php
http://pastebin.com/0VgXvtJp
src\RedK\Core\IndexBundle\Entity\AccountsRoles.php
http://pastebin.com/GiKNnYg3
src\RedK\Core\IndexBundle\Entity\AccountsRepository.php
http://pastebin.com/SVuMVdpN
MySQL demo_template.accounts Table
http://pastebin.com/YzmjD9e4
MySQL demo_template.accounts_roles Table
http://pastebin.com/Ybwr4f7y
All aspects of the bundle were working correctly (registration, confirmation, password reset, and login) before I attempted to add the loading of user roles from a database. When I simply set the role to array('ROLE_USER') via the getRoles() { return array('ROLE_USER') }, authentication worked and the user successfully logged into the site.
However, upon attempting to integrate roles from the database, I receive the following error, which I understand is an instance of AuthenticationException:
Notice: Undefined index: id in /home/humplebert/Websites/www/template/vendor/doctrine/lib/Doctrine/ORM/Query/SqlWalker.php line 804
Stack Trace
http://pastebin.com/Sr5RvZaY
The exception is only generated when I modify the query in AccountsRepository and remove
the "->select()" and "->leftJoin()" components. In looking at the Stack Trace, around line 16 on the pastebin.com link, it appears I have all sorts of "crazy" happening with regards to the many-to-many mapping in the BasicEntityPersister.
I've searched high and low in my Entity classes for any reference to plain "id" and can find none. I've noticed that if I change the names of my "ID" columns in my entities to just "id" (i.e. replace "AccountsID" with "id" in src\RedK\Core\IndexBundle\Entity\Accounts) the error goes away (and is replaced with another error, more on that in a moment).
Question 1)
Is there something blatently wrong with my Entities to be generating the "Undefined index: id" error I am receiving? If not, does Symfony2/Doctrine2 require that Auto-Increment columns in be labeled "id"?
As I have continued to tinker, I decided to try renaming my table ID columns to "id". Therefore, src\RedK\Core\IndexBundle\Accounts replaces AccountsID with just "id". And likewise, src\RedK\Core\IndexBundle\AccountsRoles replaces RolesID with just "id". Upon doing so, the "Undefined index: id" error goes away. However, I am presented with a new error: "table or view demo_template.accounts_accountsroles does not exist". Well of course it doesn't exist, I don't have a table defined as accounts_accountsroles. I have two tables, accounts and accounts_roles.
Question 2)
In order to use the Symfony2/Doctrine2 tools for importing user roles from a database, what rules are there regarding the naming of the tables? Based on the error I received, it seems that some form of concatenation is taking place. Or have I just simply screwed up my annotations somewhere along the line?
Any help would be greatly appreciated.
Regarding Question 1) the short answer is no! For the long answer see section 5.3 Mapping Defaults in the Doctrine Association Mapping documentation:
It states that if you use this short annotation:
/** #ManyToMany(targetEntity="Group") */
private $groups;
"In that case, the name of the join table defaults to a combination of the simple, unqualified class names of the participating classes, separated by an underscore character. The names of the join columns default to the simple, unqualified class name of the targeted class followed by “_id”. The referencedColumnName always defaults to “id”, just as in one-to-one or many-to-one mappings."
You can override the defaults by providing more detailed many to many annotations (see link above) and therefore avoid the id error.
Regarding Question 2) the concatenation is correct. Many to many relationships require a third 'junction' table. The Doctrine paragraph above explains how the name of this table is generated.
I don't know why the 'table ... does not exist' error is occurring for the junction table as the annotations look ok to me. It appears as though your database schema is somehow out of sync with your annotations.
I implemented a solution, above FOSUserBundle and described it here
After implementing Role access throug Doctrine you still need to make a RoleHierarchy service aware of it.
I have a stored procedure that search a view using full text.
I'm trying to map the results to an existing Entity (Sales), where I mapped the column MivType to SaleType (as it makes more sense, and I want to keep db names away from my web site). The stored procedure is mapped to a Function Import, and I've defined its ReturnType to Sales.
This work well as long as the entity has the same property names as fields names.
Here's my problem: when I change the property's name, I get the following error after running the imported function:
The data reader is incompatible with the specified 'Model.Sale'. A member of the type, 'SaleType', does not have a corresponding column in the data reader with the same name.
I can fix this if I change the property 'SaleType' to 'MivType' on the entity, but why should I do that? Isn't that what the mapping is for?
This means I have to use the exact same names on the stored procedure and the entity, so in effect, the mapping is ignored (I have names like YzrName, MivYaad, etc, and I don't like it).
Is there a simple way around this? I don't want to use the db names on my application, and prefer not to change the stored procedure...
(I should mention I'm a beginner with the EF, so this can be a rookie mistake)
Thanks.
Well the entity designer doesnt work very well. I generally try to do everything in the XML. In the XML there are 3 parts. The Storage (a representation of the SQL Database). The Conceptual (a represention of your .Net Objects. and the Conceptual to Storage Mapping
It sounds like the error is in your Conceptual to Storage Mapping. You can keep the property name SalesType on the conceptual side but the mapping must map the the correct names on both the conceptual and storage side.
Refer to MSDN here are some articles
http://msdn.microsoft.com/en-us/library/cc716731.aspx