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())
Related
When using TornadoFX, TableView columns are established like this:
tableview(list<ObjectType>) {
column("ColumnName", ObjectType::property)
...
}
This is normally fine, but in my case I'm using a Kotlin Exposed entity that's using a reference to another entity. When that happens, if you want to use that reference, you have to surround it in a transaction.
Example:
val company = transaction { employeeObject.companyObject }
If you don't wrap a call like that in a transaction, an error gets thrown. There doesn't seem to be an obvious way to override how a column accesses a property, so I'd like to know if it exists.
Now, I've already tried to wrap my entity in another class that would do all the necessary transactions up front but when the amount of entities that need to be mapped gets in the thousands, it causes my program to basically go into a stand still. If need be, I can go back to how it used to be, which was to not have a reference, but just the plain old ID number to the other entity. Then the cellformat of the column would try to match the company to all companies in a list that was grabbed earlier. I don't really like that solution though, it seems uglier and less elegant, but it's a lot faster than mapping entities. There's also the chance that what I'm trying to achieve might also cause its own slow-down. I'd just like to know if this is possible so I could at least see how fast it is.
Thanks, Edvin, for reminding me that columns work on the UI thread and that it shouldn't be doing the heavy lifting! I tried a few other things with mapping, hoping that the choke point was the amount of transactions I was doing, but it didn't help with speed. So I think having my View retrieve a list of all companies up front, then having my columns find the companies in that list is the way to go. Not as pretty, but no slow down!
But to officially answer my own question: It doesn't matter, don't try it in the UI thread. It's bad practice and will kill performance.
I am working on a legacy application where NHibernate has been used without any apparent thought to efficiency. I am currently stepping through a method in which over 200 queries have been executed so far. This is mostly due to the N+1 problem.
Anyway, as I think about fixing this, my question is:
Given an entity with, say, 10 child collections, almost all of which will be accessed during a single operation, is there a way to lazy-load each child collection in a single call rather than have NHibernate lazy-load each individual child record as it is accessed (e.g., in a foreach loop, which is what's happening now). It seems to me that eager loading all of these child collections at once would be a massive query and not very performant. But obviously this N+1 approach is wrong. How can I tell NHibernate to do a query that loads up the whole child collection on demand? This still gives me 11 queries, but it's better than 200 and, perhaps, better than the massive query I'd have to do if I eager loaded everything.
Thanks!
You can use the method NHibernateUtil.Initialize(yourObject.ChildCollection). This method forces proxies to load their data based on their fetching strategy, that you set in your mappings. Source: NHibernate documentation
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
As many of you may know, an NSTreeController bound to an outline view can display duplicates while presenting core data entities.
A temporary solution is to add 'parent == nil' to the predicates, but this only returns parent entities. If, for instance, a user is searching for a sub-entity, the requested sub-entity won't be displayed.
A (proposed) solution is to subclass NSTreeController and add a NSMutableSet variable, which keeps track of entities that are currently being displayed. This variable should be alloced on init, and released on dealloc.
When "fetchWithRequest:merge:error:" is called, the set should be emptied (I'm not sure whether this would be more efficient than releasing it and allocating it again). Everytime an entity is going to be added to display, check if the set contains it. If it doesn't, add it. Otherwise, find which is closer to the root (which is the subentity) and either skip it if its the subentity, or swap it with the previously included one.
I think there should be relatively little impact on performance (considering NSSet uses hashing). The problem I'm having is finding the correct method to override to add this behavior. Specifically, where NSTreeController processes fetched entities after "fetchWithRequest:merge:error:" is called.
Is it fair to say you're really looking for a way to filter the tree with a search term without losing the tree structure? The inherent problem (beyond forcing the tree controller to include the parent nodes of a search match) is that the parents may or may not actually match the search result, so it's confusing to display them.
I think yours is more a problem of UI, isn't it? In that case, the best approach (and one I've seen many well-known companies and independent developers take) is to display search results in a plain table. This way the results can be sorted by various attributes and you don't have to disable drag and drop in the outline view in search mode (to avoid the user trying to change the tree structure when only part of the tree is displayed out of context).
Expanding on Joshua's answer, I was able to implement Search Functionality into my own NSOutlineView, however it was limited to the root/parent objects in the view.
I think (like Joshua said) if you wanted to filter all objects you would have to display the results in a NSTableView.
i am looking for repository pattern sample that i can learn from it and i have read lot of blogs and seems like everyone has their own opinions towards -implementing repository pattern-
any help?
Thanks,
Here it's
The repository pattern and Linq to Sql won't match. Sorry.
IMHO, pretty much all I-hide-data-storage-from-u patterns are broken in one way or another. Either you have leaky abstractions or they require LOTS of redundant code.
Imagine this... You have an IRepository which uses Linq to Sql to generate a Foo type that matches a Foo database table. Awesome! Everything worked out better than I expected.
Except the Foo table is linked to the Bar table. So now when you return all Foos via the IRepository interface for Foo, you have to keep your DataContext alive so that if somebody goes foreach(var bar in Foo.Bars) they'll get what they expect.
But how do you manage that DataContext? Do you keep one for all instances of IRepository or one per instance? What happens when a Bar is created, a new Foo is added to it, and saved to the IRepository? You've added a Foo without the Foo repository! And it gets worse, with side effects from not using the L2S pattern correctly come creeping out of your IRepository.
So you try to scope your L2S types within your IRepository implementations, duplicating all your data within new types that you coded by hand. But then how do you handle one-to-many and many-to-many relationships? Load it all into memory, or load a piece by piece, ensuring you lose any way to make efficient queries to the database?
The whole frigging thing is depressing. It would be wonderful to be able to hide the fact that you're not actually storing your data in a database, but unless you're lucky (i.e., your design is simple), you're not going to be able to get away with it.