I have a GWT application with Requestfactory. On the serverside I have a service returning a triple nested object. A contains a List<B> #B. Each B contains a C.
When I fire my request to findAll(A).with("B","C").fire(receiver) it only returns B values. C is null. In debugging I see that up to the DAO the A object is properly set with all values.
(Clientside all extend EntityProxy)
Right now I need to fire seperate requests to get C for every B selected in the list of A. Which means more back and forth...
Thanks
If A contains B, you need .with("B"). If A contains C, you would add "C" to that call, but since B contains C, you instead add "B.C":
findAll(A).with("B","B.C").fire(receiver)
Real world example: Person (A) has Address (C), and Person has Employer (B), and Employer also has Address (C). You were asking RequestFactory to send Person, their Employer and the Person's address, but not the Employer's Address.
Related
We use Eclipselink-2.6 with wildfly-8 server in a JavaEE7 application.
we have three JPA entities A, B, and C.
B and C extend A.
In order to change the type of an object "myObjectId" A to B, we try to:
1- Change the dtype value from "a" to "b" in Table "A" for the instance "myObjectId" using the criteria query.
2- Create a new row in the table "B" in the database for the same id "myObjectId" also with a criteria query.
3- Clearing the cache by evictAll as well Entitymanger using clear functions.
After, when I tried to find all data of type B, the object "myObjectId" came in the list but with type A!
After restarting wildfly server and call findAll, therefore, the data came with type B!
why myObjectId didn't change its type even if the first and the second level cache was cleared!?
See https://wiki.eclipse.org/EclipseLink/Examples/JPA/Caching
Essentially EclipseLink maps the JPA cache eviction call to its own invalidation logic, which seems to be keeping a reference to the object using a soft reference so that object identity is maintained. This prevents A1->B1->A1' from happening on cycles with lazy relationships.
Try calling ((JpaEntityManager)em.getDelegate()).getServerSession().getIdentityMapAccessor().initializeAllIdentityMaps() as suggested in the doc and then reading in the changed class.
I have an entity A and an entity B that extends A.
let's say A is a basic profile and B is a more complete one.
I look up in the bd to find A and I have to cast it in B to be able to get the more advanced profile.
I've tried to downcast but then JPA complains about detached entity.
I've tried to use a constructor in B that takes A in arguments, but still JPA complains.
I'm trying to find more information about it withtout that many success.
A and B are in 2 different tables, but when I create B directly everything is fine (B and A having the same id in their own table)
Any idea how I can get a A and convert it in B and get JPA to work as expected ?
Thanks !
I am having a problem when updating/merging an entity A which has a reference to another entity B. A also has a reference to an entity C.
I create a new instance of the entity A from a domain object. Also from this domain object I use the ids to get B and C by using entityManager.getReference(<class>, <id>). I call entityManager.merge and entityManager.flush(). So far all is good, the values of both B and C are present in A. When I after the flush do a entityManager.refresh(A), the B is cleared(null), but the C is still there.
I run sql queries to verify that the value is there before the update. After the flush the FK to B is cleared, so when the refresh is called it discovers this.
I do not know what to look for here. Might it be something with how my entities are defined? Persistence-xml? Any tips are much appreciated!
EDIT:
The value of B is only cleared if I do not change the reference. If I change the reference of B to B', then it is updated correctly
The question did not show the entire context of where I was experiencing the problem. The entity A which had a reference to B, also had the foreign key field in it. This foreign key field was always null, so setting the entity reference had no effect.
So I looked into neo4j, and I may be using it in an upcoming project since its data model might fit my project very well. I looked through the docs but I still need an answer to this question:
Can I set relationships to be one-directional?
It seems that the neo4j people like movies so let's continue with that. If I have a graph like this:
Actor A -> [:Acts in] -> Movie B
then direction is obvious, because the nodes are different types.
But I like horror movies so...
Person A -> [:wants_to_kill] -> Person B
I need this relationship to be one-directional so if I query "Who does Person A want to kill?" I get Person B, if I query "Who does Person B want to kill?" I get nothing.
Sometimes I still need relationships to be two directional
Like:
Person A <-[:has_met] -> Person B
...which is obvious.
documentation says:
Relationships are equally well traversed in either direction. This means that there is
no need to add duplicate relationships in the opposite direction (with regard to
traversal or performance).
While relationships always have a direction, you can ignore the direction where it is
not useful in your application.
So docs say, relationships by default have an direction and I can ignore that if I wish.
Now this is where things get complicated:
Consider the following graph (and note the arrows)
Person A <- [:wants_to_kill] -> Person B
Person B -> [:wants_to_kill] -> Person C
Person C -> [:wants_to_kill] -> Person A
If I ignore the Directions for all [:wants_to_kill] I get false results
for "Who does Person A / C want to kill?"
If I knew which ones I had to ignore, I would not do the query.
So can I somehow set relationships to be two-directional (when creating them), or should I model this with two relationships (between Person A & B)?
A relationship in Neo4j always has a direction. If a relationship type's semantics do not incorporate a direction, e.g. has_met from your example, then it's best practice to apply an arbitrary direction on creation of the relationship. Querying is then done by using the "both directions" (there is no "larger/smaller than" character) notation in cypher:
start ... match (a)-[:HAS_MET]-(b) ....
In contrast, if the semantics of a relationship do have a direction like your wants_to_kill, you need to use two relationship to indicate that a and b wants kill the other one and vice versa. For the example above, you need to have 4 relationships:
Person A -[:wants_to_kill]-> Person B
Person B -[:wants_to_kill]-> Person A
Person B -[:wants_to_kill]-> Person C
Person C -[:wants_to_kill]-> Person A
To find all the person that A wants to kill you do:
start a=node:node_auto_index(name='A') match a-[:wants_to_kill]->victims_of_a return victims_of_a
To find all persons who want to kill A:
start a=node:node_auto_index(name='A') match murderer_of_a-[:wants_to_kill]->a return murderer_of_a
I have an ERD with a main table (A) which has one attribute(String) that is a FK to another table (B).
The issue that I have is that in B the only attribute is the PK; I just want to ensure that the user inputs only one of the allowed values in the main table attribute. I do not even want to update the B table from the application, as it will be a task so unusual that I'll do it directly in the DB.
I could treat B just as another Entity and deal with them with "regular" JPA, but I am a little troubled that maybe there are more efficient ways to do it*. All I want from B table is to get the full list of values and to ensure that the attribute value is correct.
So the question is: there is a specific pattern in JPA to deal with those master tables?
Thanks In advance.
*: My concern is creating / retrieving Entity B objects when all that it is needed is an string, every time an Entity A object is created retrieved.
I would simply use a native query to get all the strings from the B table, or map B as an entity to retrieve all the B Strings using a JPQL query, but not have any association from A to B.
The B string would be stored as basic String column in entity A. And if you try creating or updating an A instance with a string that is not in the B table, then you'll get an exception at flush or commit time because the foreign key constraint is broken.