I read the documentation and I see that the limitation when using IncludeFilter is that I can't combine it with EF Include. Has anyone came into this situation where they used IncludeFilter but needed to load a navigation property that originally would have been handled by EF Include? What's the best way to load the additional navigation property?
https://entityframework-plus.net/query-include-filter
It's currently impossible to combine IncludeFilter and Include. That's a limitation of our library.
However, you can use IncludeFilter without a filter. So to make it work, you just need to replace ALL include by IncludeFilter no matter if there is a filter or not.
Related
I am trying to code a medium sized full web application based off dojo.
I have a basic BorderContainer that is placed at the document.body.
In order to make code maintainable and easy to read, I want to put fully contained widgets/modules in each of the sections. That can be simply added by a couple lines such as...
var topTabs = new TopTabs();
top.addChild(topTabs);
And then I want to stitch them all together so that they can invoke work in each of the other widgets, in order to follow the MVC model.
So for instance, one example that I would like to insert the following widget that is fully contained into the top section that looks something like...
So my question is....
What is the best way to create these fully defined and encapsulated widgets/modules?
Since my widgets will also contain other Dijits, then are template based widgets the route to go? Or is it better to create widgets/modules that are purely programmatically defined?
Thanks
Depends how much you are familiar / comfortable with declarative/html (templated) versus programmatic/javascript. You can definitely go both routes;
I seldom use templates, which are static by nature and mean two set of entities in two languages, usually two files, to account for. Besides, with dojo/dom-construct & dojo/dom-style, I have an effective dynamic replacement to html templates, allowing to build self-contained complex widgets
jc
Your going to want to read about making custom dijits (widgets) - https://dojotoolkit.org/documentation/tutorials/1.9/recipes/custom_widget/
templates vs programmatic is more of a personal choice. templates are much easier for a UX (non dev) to work with. i like to use templates as it reduces the clutter in my js files i prefer to keep things separate logic (js), style (css), and structure/layout (html).
Before Hibernate Search 5.2 there was no need to explicitly use a #Facet annotation. In 5.2 it became necessary in order to use Lucene’s native faceting API.
I'm using Hibernate Search on external classes that cannot be annotated. Is there a way to define this "facet" programmatically?
For the mapping configuration, there is no issue because the SearchMapping provides a complete programmatic alternative to the #Entity, #Indexed, and #Field annotations. But within this API, and in particular in the EntityMapping class, there is no way to define that a field will be used in a facet query; there is no other alternative rather than annotating the field with #Facet.
2018 update:
I've updated to Hibernate Search 5.6.4 and it is working with this kind of mappings:
.property("businessProcess", ElementType.METHOD)
.field()
.analyze(Analyze.NO)
.store(Store.YES)
.facet()
.name("businessProcess")
.encoding(FacetEncodingType.STRING)
The workaround you referenced does not configure faceting in Hibernate Search at all (no #Facet annotation nor programmatic equivalent). In recent versions of Hibernate Search, this will not work, because we had to require this metadata in order to fix other bugs.
Using custom facet formatting is very much uncharted territory, and admittedly much harder than it should be. The main reason is that facets were originally, for a reason I cannot fathom, designed to work directly on the entity property instead of the field value. Thus, facets ignore the field bridge. We're working on cleaning up the faceting support in Search 6, but this one of many works in progress and will take some time.
In the meantime, your easiest option will probably be to just use the built-in formatting.
EDIT: Also, for dates you might want to use numeric facet formatting, so as to perform range faceting (from the first of May to the 30th of may). In that case, the name of facets is defined at query time, so built-in formatting should not matter.
And there's actually one easy solution to customize formatting in your string-encoded facets, but I didn't mention it since you are using programmatic mapping and probably do not want to change your model: you could add read-only properties returning the exact value you want in your facet (getYear, getMonth, ...), and add fields with faceting on those properties.
I got a legacy database which have about 10 identical tables (only name differs).
Is it possible to be able to use the same business entity for all tables without having to create several classes/mapping files?
You can use the entity-name feature if you are using NHibernate v2.1 or higher. It is poorly documented but I am actively using the feature. It has gotten hard to find the documentation on it but look here:
Section 5.3 in
http://docs.jboss.org/hibernate/core/3.2/reference/en/html/mapping.html#mapping-entityname
A couple of things to be aware of. You must now use entity-name instead of class name to refer to the objects. In general it is not an entirely transparent change moving from class names to entity names.
Session actions now require two parameters, for example:
_session.Save("MyEntity", myobject)
The entity-name controls what table the data goes into.
Some HQL queries do not work right anymore, sometimes you must use Criteria instead.
If you need a set of sample code I may be able post some, but far too busy at the moment. I suggest you look at the limited info you can find and set it up for a very simple object and multiple tables to learn how it all works. It does work.
You can create a base class with all the properties, but you still need to map them all.
For that, you can either use copy&paste, XML entities (see examle at http://nhibernate.info/doc/nh/en/index.html#inheritance-tableperconcreate-polymorphism), or a code-based mapping method (Fluent or ConfORM). They usually make reuse easier.
I'm currently using NHibernate, for the first time, with Fluent NHibernate. I've gotten everything setup nicely, however now I've come to actual doing some data retrieval, it seems to have fallen short.
I was expecting NHibernate, to allow me to do something like:
session.CreateCriteria<TblDocket>()
.Add(Restrictions.Eq(x=> x.DocketNumber, "10101"));
However, this doesn't appear to be the case and I seem to have to write:
session.CreateCriteria<TblDocket>()
.Add(Restrictions.Eq("DocketNumber", "10101"));
That'll be less-than-wonderful when I rename any properties! I've always though hard coded strings in code is bad, especially when the strings relate to property names.
Is there any way I can strongly type these restrictions? I had a look at this blog post, but it seems quite messy, is there a nicer solution?
I decided to use NHibernate.Linq instead. I found a brilliant tutorial here.
You can't using out-of-the-box NHibernate.
There is a project called NHibernate Lambda Extensions which allows you to do this with some limitations.
since NHibernate 3.0 there is also QueryOver available which are a nice typesafe wrapper around the criteria API.
session.QueryOver<TblDocket>()
.Where(x => x.DocketNumber, "10101");
For anyone who comes along this post and doesn't like linq or isn't too familiar with lambda you can still safely use ICrierta's such as
session.CreateCriteria<TblDocket>().Add(Restrictions.Eq("DocketNumber", "10101"));
what you need is helper classes so you can remove the magic strings such as "DocketNumber" so that if you do change your property names or column names these are taken care of for you or will atleast produce a build error so you know before you publish your code.
Anyone wanting to see an example can have a look at NhGen ( http://sourceforge.net/projects/nhgen/ ) and the query examples at https://sourceforge.net/projects/nhgen/forums/forum/1169117/topic/3789112 which show how helpers classes can be used like.
// Find using a simple entity query
IList<IMessage> messageList3 = messageDao.Find( new [] { Restrictions.Le(MessageHelper.Columns.Date, dateLastChecked) } );
Note that this project also created entity wrapper classes which group all your common CRUD methods into one class (xxxDao as show above) so you don't have to keep copying the same code over and over again.
I may be going mental, but I can not find any api reference material for nhibernate. I've found plenty of manuals, tutorials, ebooks etc but no api reference. I saw the chm file on the nhibernate sourceforge page, but it doesn't seem to work on any of my PCs (different OSes)
Can someone please point me in the right direction?
I just found this one:
http://web.archive.org/web/20141001063046/http://elliottjorgensen.com/nhibernate-api-ref/index.html
It doesn't seem to be official, but at least it looks like an API reference... unlike the official reference, which mostly describes concepts and mappings without any information about classes and members.
If you're on Windows, get ILSpy and point it at NHibernate.dll. It's not quite the same as real API documentation, but it's not half bad.
There is no class references publicly available on Internet as far as I know. You may build it from the source. Clone them, build the NHibernate.sln solution, then go into doc folder, ensure you have prerequisites indicated in reference\readme.txt file, and run nant doc. This will generate the class reference in the build folder.
Otherwise the most commonly used API are not wide, and most of them are xml documented with intellisens working in Visual Studio. The reference documentation has the advantage of giving more context, probably helping avoiding pitfalls like believing ISession.Update is to be used for updating entities (this is wrong, you do not need it unless you use detached entities, or entities coming from another session).
Official documentation reference is on https://nhibernate.info.
Sub-links:
Global documentation list
Reference (What I mostly use, especially following sub parts.)
Configuration
Mapping - basic / entities. (Add mapping xsd definition file in any or your solution folders for letting VS know it and give you intellisens in your hbm mappings.)
Mapping - collections
Querying - general. Do not miss the named queries feature in The IQuery interface.
Querying APIs:
HQL. I mostly use HQL with named queries, in mappings, for queries not dynamically built. They get parsed and validated when building session factory, which normally occurs at application startup, so it is almost as good as compile time validation. Checks log4net logs to get detailed reasons of named query parsing failures.
Criteria API. I view it as the historical way of dynamically building queries in code, to be preferred over constructing HQL strings.
QueryOver API. Based on Criteia API, with lambda expression support for having compile time validation of queried entities namings. Should be preferred over Criteria API in my opinion.
Linq API. Great for dynamically built queries. Bear in mind that its implementation translates your queries to HQL. With complex queries, it may generate unsupported HQL constructs. Having knowledge of HQL capabilities allows a better understanding of how to write a supported Linq query for complex cases. (By example, for a complex order by, better use an explicit linq sub-query in the OrderBy rather than using a collection mapped on your queried entity.)
Native SQL. Well, quite self-explanatory. To be used by example when you need some SQL special feature not available through other querying APIs (SQL server full-text, select for xml, ...), and that you do not wish to extend those other APIs. You may also call stored procedures. When using native SQL, I favor SQL named queries.
Modifying data, from Updating objects to Flush, and Exception handling.
Performances.
Batch fetching. About this, you may read my post here for a detailed explanation of why lazy loading can be very efficient with NHibernate, thanks to batch fetching. This single feature will always cause me to prefer NHibernate over Entity Framework, till it ceases being lacking in EF.
Second level cache. Another great NHibernate feature, lacking native support in EF. Beware, you must use transactions for leveraging this. It allows NHibernate to automatically evict cached entries for you as you change data through your application process. Without transactions, NHibernate will disable the second level cache as soon as you start changing data, for avoiding letting the cache yield you stale data.
Interceptors. This is one way among many allowing to customize NHibernate inner working. NHibernate is very strong at allowing you to extend it. You may also add your own HQL extensions as here, your own linq2NH extension as here (all are answers from me). And there are other ways, see this list for linq2NH extensibility solutions.
Moreover, a class reference will very likely be near the Hibernate one. There is so many internals APIs supporting its implementation that is not much usable.
Why are such API not hidden (internal, private, ...)? Not hiding them is required for allowing the great extensibility capabilities of NHibernate. Those capabilities are a must have in my opinion. In contrast, it is so hard to fix some other .Net project shortcomings, due to lacks of extensibility they suffer. (MVC FileResult and the TweakDispositionAsInline I had to use instead of just being able of overriding some method, or try extend linq-to-entities, see this.)
there is a good book that covers a lot, and there is the html documentation on the site (which also comes as a book)
(the book would be manning - nHibernate in Action - a little outdated, but a good start)
Here is the link to the online reference