I am using Spring data Neo4j project while my nodes contains relations properties using #RelatedTo , #RelatedToVia annotations, I don't want any of them to be fetched eagerly so these properties ain't marked with #Fetch annotations.
When node is fetched all his other relations are partly fetched ( each fetched related node only with id the rest of the properties are null) this happens in nested way also for the relations of the relations.
There is way to prevent this overhead? using include/exclude fields like in spring data mongo db?
Thanks
You can have a look here to get a better understanding how the lazy/eager loading in Spring Data Neo4j works:
lazy loading in spring data neo4j
But what you have to remember is that in general what you don't have marked with #Fetch annotation you have to get it yourself with neo4jTemplate.fetch().
This means exactly what you found out by yourself, that if you fetch a property using #RelatedTo annotation, then you have to use fetch for the properties of that property using #RelatedTo annotation.
As far as I know there is no way you can use to avoid this.
Related
Is there a way to use a 'transient' field or something like that and in some way sort accordingly with a NSFetchedResultsController. I want to do the following:
I have location of places in a database. When a person opens the list, I want to show the nearest place on top, an then sort accordingly to distance. But clearly,this depends on the users location, so I cannot use a static field. I was hoping to use a transient field, as you can use for the section headers.
Is there anybody who can give a solution or workaround for this situation?
You cannot use a transient property in a fetch request for a SQlite base Core Data store.
See Fetching Managed Objects in the "Core Data Programming Guide":
You cannot fetch using a predicate based on transient properties
(although you can use transient properties to filter in memory
yourself). ... To summarize, though, if you execute a fetch directly, you should
typically not add Objective-C-based predicates or sort descriptors to
the fetch request. Instead you should apply these to the results of
the fetch.
You can use a transient property for sectionNameKeyPath, but even then you need a first sort descriptor for the sections that is based on a persistent attribute.
So the only workaround is probably to fetch all objects and then sort the fetched array. But then of course you don't have the advantages of a fetched results controller anymore.
I am using nservicebus to handle commands. During a handler i use nhibernate to load my domain object. I use session.get for this. Is there way to provide a correct fetching strategy based on which handler I am executing?
I saw hibernate had the option to set a fetching mode on the session before doing the get, but could not locate this in nh3.2
You can specify lazy/eager in your mappings but you will have to use different mappings for each handler then, however why not use a query instead of session.Get and specify the fetching strategies there?
as you know, in Seam there are no problems with LazyInitializationException when reading entities's references to subobjects. So is there any problem if I favor running through the tree of relations in order to read the data that I need, instead of sending specific queries to releveant entities' DAOs? Do I break some important guidelinies/priciples?
Consider that the phrase:
"in Seam there are no problems with LazyInitializationException"
It's not true.
In seam there are no problems with LazyInitializationException if you use a pattern where your session is being persisted in the boundary of a long-running conversation.
This means using a Seam injected persistence context like:
#In
private EntityManager entityManager;
Or, if you are using stateful EJBs (bound to conversation scope too):
#PersistenceContext(type = PersistenceContextType.EXTENDED) EntityManager em;
BTW, once you have understand that, there is no problem navigating the relation tree. You should really do it, if you want to bind it to the interface using JSF.
Consider that you may incur in some speed problem if you access to ManyToOne or OneToMany relations in queries that returns more than one result. This is known as n+1 problem, when you basically runs one more roundtrip to the database for each record returned.
Let's summarize:
single detail object -> navigate relation tree
List of other object -> make a single query to the DAO using left join fetch.
By default, NHibernate lazy loads all collections, which works fine for me in most cases. However, I'm running into problems with some tools that use reflection, which doesn't play well with proxied objects. In this case, I can't serialize an entity using JSON.NET because it throws an exception when it hits a proxied object.
My question is, is there any way to tell a session to disable lazy loading on ALL entities for the lifetime of that session? I know you can do it for a particular type but I want to be able to do it for all entities.
You can use sessionFactory.OpenStatelessSession(), and you'll get an IStatelessSession instance, which doesn't use lazy loading.
Be aware that IStatelessSession has a simplified model that doesn't track changes. It seems adequate for your use case, though.
I believe that this is not possible as classes and properties become lazy (through configuration - XML or Fluent) when the ISessionFactory is build and that happens only once at the beginning of the application's lifetime. It is there, that the actual proxy classes are generated and used to take care of lazy loading.
I do not know if it is helpful for you but you can get the underlying proxy's type (the actual entity type) like this:
Type t = entity.GetType().BaseType;
"entity" being your antity that comes as a proxy.
Furthermore you can instead use DTO's to serialize with JSON.NET instead of the actual entities using an object-object mapper like AutoMapper to assist you on that.
If you don't want to use the stateless session for whatever reason, you can eager fetch in your query.
Criteria:
.SetFetchMode("ClassName", FetchMode.Eager)
HQL:
string hql = "from Order o" +
" inner join fetch o.OrderLines" +
" inner join fetch o.Customer" +
" where o.Id=:id";
I am using Nhibernate but still i am confused about (lazy-loading and Eagerly loading) these two topics due to poor understanding of Nhibernate.
Please define me lazy-loading and Eagerly loading in simple words.
Also why we use castle.Dynamic Proxy ?
Lazy loading and eager loading are concepts that must be present in every ORM.
Let's take a parent-child relation:
class Parent {
String name;
List<Child> childs;
}
class Child {
String name;
}
When you load an element of Parent, the ORM must decide if it loads the childs collection also (through a join for example) or if it delays the query to load the childs until you actually access the collection
parent.childs.get(0)
When you load the childs collection ahead, ie, before accessing the collection, it is eagerly loading because you are expecting to access the childs. This can be done in a single query, with the disadvantage of bringing more data from the DB.
When you delay the load until the actual collection is accessed, it is called lazy loading, because you are only getting the childs when they are strictly required. This has the benefit of getting only the data when its needed, at the cost of extra queries (for mor on this topic you can query google for "N+1 select hibernate" for example).
If you want to trigger the query for retrieving the childs when the collection is being accessed, you need some sort of callback/interception on the childs collection. This is done through a proxy on the collection, so you can intercept every access to the collection to get data from the db. That's why you need a proxy/interception library such as Castle.
Lazy loading = waiting until code explicitly accesses a property/collection before loading it from the database.
Eager loading = proactively loading that data ahead of time, regardless of whether the code ever uses it or not.
Proxies are used to intercept access to said properties/collections in order to instigate the load.