What is the query for getting the classes which are using parallel inheritance hierarchies?
Related
I have been searching on EF Core documentation, if adding .HasIndex() on your entities mappings would bring any benefits on a DbFirst scenario, and I couldn`t find anything.
I have this 20yo DB that has all the necessary tables and indexes created, and I am mapping some tables to query them using EF Core. I wonder, what could be the benefits of mapping the indexes on a DbFirst scenario where you would never update the tables schema via code? Does it affect the way EF generates the SQL queries?
None. HasIndex would only apply to creating indexes for code-first/migrations. You don't need to map indexes for EF to generate or optimize the query.
I do recommend after introducing EF to a project to record/report on the most common queries executed to determine whether there are new indexes or adjustments to existing indexes that might benefit your application's performance. (I.e. included columns)
What's the best approach for doing multi-table aggregates, or non aggregate multi table results in my Spring Data repositories. I don't care about mapping back to entities, I just need a list of objects returned I can massage into a JSON response.
If you don't care about entities, repositories are not the tool for the job. Repositories are defined to simulate collections of aggregates (which are special kinds of entities usually).
So to answer the question from your headline (which surprisingly seems to be the opposite of what you're asking in the description): just do it. Define your entity types including the relations that form the aggregate, create a repository for them and query it, define query methods etc.
If you don't care about types (which is perfectly fine, too), have a look at jOOQ which is centered around SQL to efficiently query relational databases, but wrapped into a nice API.
Is it possible to provide hints to the Include linq queries so that the joining of the child tables can be optimized ?
I have a very generic data model and so, there are multiple referential constraints between tables. I am working with a legacy system, so changing that around would be very difficult.
I have a query like the following, which generates very complicated SQL queries.
var links = A.B.CreateSourceQuery()
.Include("B1")
.Include("B1.C1")
.Include("B1.D1")
.ToArray();
Is there a way to provide hints to the above query, on how to join the respective child entities, so that the SQL generated is more optimized and efficient and the data can be eager loaded.
See my post at http://www.thinqlinq.com/Post.aspx/Title/LINQ-to-Database-Performance-hints particularly the point around breaking up complex queries. In the case where you're fetching two sets of grandchildren, your performance may well suffer. You may want to consider a custom projection instead of multiple includes.
I have a JPA / JPQL query in EclipseLink 2.3.2 and I'm providing a batch-fetch query hint on multiple collections
hints={
#QueryHint(name=QueryHints.BATCH, value="obj.collection1"),
#QueryHint(name=QueryHints.BATCH, value="obj.group.members"),
#QueryHint(name=QueryHints.BATCH_TYPE, value="IN"),
}
Is there a way to specify different batch fetch types on different collections, such that I can get obj.collection1 with JOIN and obj.group.members with IN or EXISTS?
Or do they all have to be the same?
The practical application is that with a fetch on nested collections, there may be different cardinalities at different levels. For example, for the initial query, there might be thousands of rows returned so I couldn't use "IN" for obj.collection1 without possibly breaking Oracle syntax limits on the IN clause. On the other hand, for obj.group.members there might only be a few distinct values of group so an IN clause would make more sense.
Is there a way to iterate query results through JPA API, similar to Hibernate's Criteria.scroll() method? It is big performance improvement with big resultsets, rows can be processed as they are read.
No, there is not such a construct in JPA. Also not in JPA 2.1.
JPA 2.2 provides TypedQuery.getResultStream(), but default implementation does not have expected effect (calls getResultList). Also specific implementations do not always lead to performance improvements, as can be seen in this article.