stop doctrine from fetching related entities - doctrine

When usually fetching an entity from database with doctrine, you get all the related entities as actual classes, which causes a huge JOIN query, if you have lots of relations.
But sometimes I just want to get the actual object, not all the associated entities, just their IDs.
Is it possible to tell doctrine to just fetch the main entity and leave alone the relations?
Update: Sorry, missed the version: I'm using Doctrine 1.2 on a old project.

By default Doctrine use "lazy-loading": it will not retrieve the associated entities if you do not try to access them.
If you just use the ID of the main entity, it will never retrieves the associated entities.
If you want it to be even more lazy, try using the EXTRA_LAZY param.

Related

DDD Laravel. Repository pattern. How to retrieve an object from persistency and convert it into a not Laravel Entity model?

I'm aplying DDD in Laravel.
In this architecture, the entity (conformed by the corresponding value objects) is not a Laravel Model extended class (because the domain layer needs to be agnostic to the infrastructure)
So... when I retrieve some data inside the repository implementation, the result is a stdclass object, and I need to return it as the entity object.
Anybody knows the best approach to do this?
Thanks!
To get this, I tried to convert from stdclass to entity by manual, but it's look hacky and dirty.
Ok, got it.
I found two different approaches, just in case others are fighting with the same problem.
Option 1: Embracing the Eloquent Active Record.
Inside the infrastructure layer, I created a Eloquent model to represent the Entity, and I use it as a vehicule for eloquent queries. Like this, all the conection with the framework stay contained in the infrastructure, without polluting other layers.
Option 2: Apply Doctrine in Laravel.
Doctrine has a package for laravel. Doctrine, as occurs in Synfony, is using data mapping, so no worries with that.
Thanks anyway!

Why is Hibernate #OnetoMany relationship required?

I have two entities Library and Books which are associated by Hibernate #OneToMany in a spring boot project. Fetching books in a particular library through the getter functions renders a LazyInitialisationException. The solution that I could find was making a query in the Books entity and fetching all the books corresponding to the library-id of the library. So, I was thinking why is oneToMany relationship required if we can just store a key corresponding to library in the Books table.
Simply storing a key doesn't provide any consistency assurances. Also, using defined OneToMany or ManyToOne you can also define the cascade types (you would only need to save the parent entity and then all the children would automatically be saved, in a single transaction).
The quick way to fix your problem would be to use FetchType EAGER, but I would recommend fixing whatever you have misconfigured.

What would happen if entity model has relations but data (views) in database doesn't have relations and if they are inconsistent?

My question is would Spring JPA throw exceptions for every query?
I mean, let say there are tables without any relation (FK) between them in database. It is bad design but you cannot change it and it is not up to you.
But you know that data itself should be as there are relations.
That's why you create Entity model with all relations like they are there.
But as I said there is no real relations in database.
And in one point data are inconsistent in database.
Would Spring JPA throw exceptions if there are inconsistency or it will just return you inconsistent data?
I assume with "relations" you mean "foreign keys".
JPA doesn't care about foreign keys.
All it cares about is if the data matches the mapping information on the entities.
So if you have an entity A that references an entity B with id b but such a B does not exist you might eventually get an exception.
Or you might just get an A with a null reference to B.
If the reference is marked as mandatory you might actually not be able to load the A in the first place, because a join is used and therefore not returning any data at all.
Side note: All this depends more on the JPA implementation you are using than on Spring Data JPA.

Querying multiple tables using jpa repository

Suppose if I have 3 entities - User, Skills, Department
and I have repositories corresponding to all of them - UserRepository, SkillRepository, DepartmentRepository.
I understand that the relation mapping between entities i.e. one-one many-many should be specified in the respective entity classes. The question is I want to use all of the 3 entities in a query. How would I do it? A single repository is associated with only one entity right? So, how/where would I write it?
As there are many different ways to specify queries with Spring Data JPA there are various answers to this.
Maybe you don't have to. If entity A references B and you just want to get the Bs with your A you simply use your ARepository to load As and use object navigation to get your Bs. You might read up on eager and lazy loading for more information about how to control this.
If you want referenced entities in the where condition you can use property paths in your query method names: https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.query-methods.query-property-expressions
If you are using #Query annotations you can do (almost) whatever you want with JPQL. Among others, you may as well navigate properties to use them in where clauses.
In general, you'd put that query in the matching repository based on the primary entity returned.

Name conflicts in Entity Framework using database schemas?

I have these two tables in my database:
client.Employee
employee.Employee
When I try to import this into entity framework I get two table objects created:
Employee
Employee1
Is there a way to handle naming conflicts that will work better than this? And really, I would prefer that my schema is represented some how for non conflicting tables as well.
Unfortunately no. Information about schema is only included in storage description (SSDL) and it is not passed to conceptual model (CSDL) so in conceptual model you have two entities named Employee and EF is using the most basic way to resolve that. Another problem is that this probably cannot be modified because generating model from database is not driven by any T4 template which can be changed whereas reverse processing (generating SQL database creation script from model) is.

Resources