I have entities which I would like to eagerly load , and on other ocassions lazy (or even extra lazy) load.
My mappings have no fetch mode declared in my YAML- so they use the default (lazy loading).
Currently the only way to eagerly load is to by constructing the DQL manually - and I need to update this every time I add a new entity.
Ideally I would just load the root entity and the force eager loading all the associated objects. Is there any way I can do this?
If not why (is there a reason beyond it being an unimplemented feature)?
If you want to use built-in repository methods (find(), findAll()), you're probably out of luck unless you set things to eagerly load in your annotations.
You'll probably want to use the query builder (or raw DQL) in some custom repository's method to force eager loading where you want it. Yes, you'll have to update that method as you add entities, but at least you'll always know what's going on in regards to lazy/eager loading, and you'll only need to maintain it all in one place.
I suppose the reason there's not some $eagerLoad flag to find(), etc, is because those are convenience methods for simple tasks. If you wanted to add such a flag, you'd have quickly get into situations where you'd want to limit recursive eager loading by depth. You'd also probably have to start worrying about cyclical references (any bidirectional association, for instance).
You can use setFetchMode() method of DQL to set mode.
See the documentation:
https://web.archive.org/web/20120601032806/http://readthedocs.org/docs/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html
Related
How do you iterate over the entities within a model in mvc 4 using entity framework 5.0? Looking for a more elegant process using linq.
Example: AnimalModel may have Cat, Dog, Pig entities. How would I detect just the entities and ignore other properties in the AnimalModel such as isHarry, Name, isWalking, isJumping. Is there a way to do this without using reflection, something within EF5 that allows for just looking at non-null entity values.
The main reason I am interested in this technique is to reduce code bloat and perform generic CRUD operations on the data across all entities and sub entities.
Possible Reference: link
I can't see how you can achieve this without using reflection at all.
You could try the following : Get all the EF types in the assembly which hosts them e.g.
var types = from t in Assembly.GetExecutingAssembly().GetTypes()
where t.IsClass && t.Namespace == "NamespaceWhereEFEntitiesLive"
select t;
You may need to ply around a bit with the above query, but you get the idea.
You can then iterate through the properties of AnimalModel, check whether the property is of any type returned in types. e.g.
foreach(var prop in AnimalModelProperties) {
if (types.Contains(prop.GetType())
}
Note that the above for loop is a bit of a guess, but the pseudo-code should clarify what I'm looking to explain.
When you use EF to insert/update, it automatically ingores all irrelevant properties. If you want an implementation that takes properties from existing objects, then applies them to the database, you could use the relatively new upsert.
If you want a custom way to upsert a graph of objects...
If you are using either database-first or model-first (if you have an EDMX), you could use T4 templates to generate code that does this.
If you want this technique to support navigation properties, you will need some sort of assumption to prevent loops e.g. update from one to many, not the other way around and not many-to-many properties, or use the EDMX's optional description to place a hint on which navigation properties to visit.
Using reflection is a simpler solution, however, although, even with reflection you'll need to decide which way to go (e.g. using attributes (which you can get the T4s to add via the above assumptions/tricks)).
Alternatively, you could convert this technique (that I wrote) to work with EF, thus explicitly specifying where to visit in the graph in the using code, (using dbset.SaveNavigation(graph, listOfPropertyPaths) instead of writing complex code that assumes what you want it to do when you write dbset.Save(graph) (I have successfully done so in the past, but haven't uploaded it yet).
Also see this related article that I have recently found (I haven't tried it yet).
By the way, null properties do have significance in updating the database, often, you won't want to ignore them.
I have set NHibernate to not lazy load for my entities. But sometimes when I do queries I don't want all the children of the children to be loaded. The mapping is set up by Fluent NHibernate.
Is there any way when writing the sql for the query to specify which columns to lazy load?
I believe, you're using the wrong approach. Set all mappings to lazy load, and then in the queries eager load only what you really need. This way you won't kill the app.
You can override all the mappings defined in Fluent Mappings in conventions either in class mappings.
There also are different scenarios where NHibernate does the trick (for instance if you load / get one instance all the properties will be fetched as defined in mapping. If you get a list of items it will not happen unless you use Fetch method explicitly).
So could you provide some more details on your question to give an answer that is more precise?
I have a domain object Foo that has an 1:n relation to a domain object Bar.
There are two major use cases where I need to get all foo's matching some criterion. In case A, I care about the bars attached to each foo, in case B, I don't. There are quite a lot of bars, so simply always loading the bars is not good for performance of case A. Similarly, not loading the bars eagerly will lead to an n+1 avalanche in case B. So neither tagging the realtion as #Lazy nor not tagging it is the correct choice.
Now, my question: Is it possible to tell the extbase persistence layer at query time whether to be lazy or eager? If yes, how? If no, is there another way in Extbase to avoid the n+1 problem (i.e. load all necessary bars and then hope that caching works when iterating through the foos)?
My last resort, of course, would be to load the foos with lazy loading, load the bars manually in a second query, and then manually set the relation.
Any suggestions?
I've been playing around with Extbase and delving into the internals in the last few months, and the upshot is this: It' impossible.
I suppose that closes this question, though not the way I'ld like.
Actually, even worse: Eager loading is not implemented at all, the #eager tag which according to the documentation sets eager loading for a relation is ignored.
what about leaving it lazy and converting it to an array when needed? (foo->bar->toArray())
I am working in a project that's work with N Hibernate. Due to performance issues and increasing in complexity of the project we need to do association manually in our code.As we all know for that we have to set lazy property true. What i want know that, is their any way to do association with set lazy property true.We have already created our own methods for filling Association.But still for that also we need to write many queries and code which is not satisfactory.
Please let me know some way for this.
Thanks.
Lazy loading is turned on by default. There is basically two ways how lazy loading is implemented by NHibernate.
Lazy loading of collections
Lazy loading of "single ended" references (many-to-one)
Collections are easy and straight forward. NHibernate uses its own implementation if the collection classes anyway, lazy loading is implemented there.
Single ended references ("normal" associations) are not that easy. Lazy loading is implemented in a proxy. The proxy is a class created at runtime which inherits from the referenced class. That's why everything in the referenced class needs to be virtual. The proxy overrides every member and makes sure that the data is loaded when a member is accessed from outside. The problem with the proxy is, if you reference a base class, you get a proxy from the base class and you can't downcast it to the real class. So be careful when using lazy loading with inherited classes.
Lazy is turned on by default, you need to explicitly turn it off. So you don't need to do anything special to get lazy loading.
When you are optimizing performance, also consider to use batch-fetching.
for single ended associations:
<class name="xx" batch-size="10">
and on collections:
<bag name="xx" .... batch-size="10">
it reduces the N+1 problem a lot (by factor of 10 in this example.).
When must we use eager loading in NHibernate? What is it's usage?
One usage is when you will cache or store an object graph (in ASP.NET Cache for instance). If you don't store the whole graph, you would be missing information on a detached object. You can reattach objects of course, but that would probably be a new roundtrip to the database anyway.
If you don't eager load your collections, you would need to touch every one of the to invoke the lazy fetch. In those cases, an eager fetch is much more useful.
Maybe this presentation by Udi can help you decide.
http://www.infoq.com/presentations/Making-Roles-Explicit-Udi-Dahan