I'm having trouble getting a connection to a Firebird database. I can't seem to find too much information on Fluent NHibernate and Firebird on the Internet which lead me to here.
Can anyone provide any insight on how to connect Fluent NHibernate to a Firebird database in C#? I'm specifically writing a WPF application.
There shouldn't be anything specific to Fluent nHibernate that causes problems with Firebird or any other database for that matter - that's the point of nHibernate, and FnH is just a layer above it.
If you post some errors someone might be able to better help you, because it's impossible to know what it is that's wrong. Can you connect to Firebird through a normal NH mapping in your current environment, for example?
Related
I have been a long time user of Subsonic due to its ease of use and LINQ integration.
I now have to use something else because I need to be able to use Oracle.
I have 2 databases with the same schema therefore I want to have 1 set of POCO's and then change a connection string to switch between SQL & Oracle depending on the requirements.
Is this possible firstly, is LINQ fully functioning and stable in NHibernate and do Castle ActiveRecord and Fluent Hibernate allow the LINQ querying?
It is stable.
It is not fully functioning, and it is not planned to be fully functioning. I don't think there exists linq providers supporting 100% everything. The question should be: "Is it fully function for the queries you need to execute?" (The answer to that question would be yes in 99% of the cases)
You can find reported bugs/missing features in Jira
Fluent NHhibernate doesn't do any querying, just mapping. Castle active record doesn't query either. The linq namespace does not have a reference to active record or fluent and vise versa.
I wouldn't classify the NHibernate LINQ implementation as stable yet. The LINQ provider is still fairly young, so chance of hitting an unsupported query scneario still may be considerable in my opinion. However, other NHibernate query options are plentiful to workaround any issues the LINQ provider might throw up.
I'm new to fluent nhibernate and generally nhibernate.
I searched a lot on the net but I couldn't find a good help.
I'm using fluent nhibernate and I mapped it with SQLServer 2008.
If there is a good help or book or sth else please tell me!
First of all I want to know how I can write native sql queries in my program? for example
DELETE * From SiteCategory
And generally I want to know how to write queries in fluent nhibernate? such as update,delete and select.
A good resource would be this series of screencasts:
Vacation Of Fluent NHibernate:
http://iamnotmyself.com/2009/10/26/vacation-of-fluent-nhibernate-introduction/
[link updated]
It was modeled after the very popular Summer of NHibernate series
I'm trying to get into using Fluent NHibernate, and I have a couple questions. I'm finding the documentation to be lacking.
I understand that Fluent NHibernate / NHibernate allows you to auto-generate a database schema. Do people usually only do this for Test/Dev databases? Or is that OK to do for a production database? If it's ok for production, how do you make sure that you're not blowing away production data every time you run your app?
Once the database schema is already created, and you have production data, when new tables/columns/etc. need to be added to the Test and/or Production database, do people allow NHibernate to do this, or should this be done manually?
Is there any REALLY GOOD documentation on Fluent NHibernate? (Please don't point me to the wiki because in following along with the "Your first project" code building it myself, I was getting run-time errors because they forget to tell you to add a reference. Not cool.)
Thanks,
Andy
I've been using Fluent NHibernate Automapping for a few months now. I'm by no means an expert, but can take a stab at your questions...
FNH Automapping does indeed create DB schemas from POCO classes, including lists of other objects (this was the reason I chose NHibernate in the first place).
When you change schemas, you have to rerun the automapping, which does drop the whole database, unfortunately. In my case, it's not a big problem because I'm importing existing binary data files, so I just have to re-import my data every time the schema changes. I've read that there's some data migration support available with NHibernate, but have no experience with this. (BTW, Subsonic will do data migration, but it's automapping functionality is far more rudimentary - at least it was when I evaluated it a few months ago)
FNH documentation is one of my pet peeves - they have not even added Intellisense help on the method names, etc. (But they get really huffy when you point that out - ask me how I know!) I've made a couple of edits to the wiki when I could, but there's so much more that could be done there. The best approach is to start with a working example (i.e.
this one from Nikola Malovic, and post questions to the support form if (when!) you run into trouble. In general, I've found the FNH community pretty helpful, and have been able to work through all my difficulties. They've also fixed a couple of bugs I've found.
Overall, using FNH has been a huge win for my project - highly recommended!
I don't use Fluent, but I can help with classic NHibernate.
yes, the creation of the schema is very recommendable for production use (Schema Export). When you do this is up to you. For instance, you could create the database by an installer. You shouldn't drop existing databases, but this is a decision of you application.
I don't understand this question. Do you mean you need to upgrade an existing database to a new database schema? This is unfortunately something you need to implement yourself. NH can't do much about this, because it is very specific to you data and the changes you made. There is also a Schema Update or something like this, which is not recommended for production use.
I don't use Fluent, so I can't help here.
Is there any supported way of mapping datetimeoffset the new datatype in SQL 2008 to the System.DateTimeOffset using nhibernate?
NH 2.1 (or compiling from NHibernate trunk) supports this and more out-of-the-box. Check it out
(Assuming google didn't turn of anything)
You will probably need to create a simple IUserType to handle this, also I am sure that the NH team would gladly accept it as a patch for everyone to benifit.
Ayende has a good post here on this. He goes though a couple of options to solve his problem so you might want to start from the bottom of the post (not the comments) and go up.
I find I can do more with NHibernate, and even Castle than with the Linq to Entities, or linq to SQL.
Am I crazy?
No you're not crazy. nHibernate is a full OR Mapper, Linq to SQL and Linq to Entities don't implement everything you'd expect from an OR mapper and targeted at a slightly different group of developers.
But don't let that put you off linq though. Linq is still a pretty good idea.. Try Linq to nHibernate :-)
The big drawbacks to NHibernate, Castle, etc., is that they're not exactly light-weight (especially NHibernate.)
Linq to SQL is good for a light-weight, limited use ORM.
I've used both NHibernate and LINQ to SQL. From my point of view it depends on the project, if I need something quick, I would choose L2S, it's so simple to create the dbml mapping and start using it. If I'm developing a more highlevel enterprise solution I would go for the tried and trusted ORM - NHibernate, I find the logging & transaction features simple to use.
LINQ to SQL has a relatively short learning curve, NHibernate has a much steeper learning curve.
LINQ to SQL only supports SQL Server, so if you've an Oracle database then the decision is already made - NHibernate.
I'd recommend checking out http://www.summerofnhibernate.com/ for excellent screencasts on learning NHibernate.
One thing to bear in mind is that NHibernate can be an absolute pig to configure - especially since its based mainly on XML config files because of its roots as the original Hibernate.
Fluent NHibernate goes some way to making this less painful.
Linq certainly though fits in with the general 'way' in which .NET works.
Blockquote Linq certainly though fits in with the general 'way' in which .NET works
Yikes, this kind of sentiment scares me. The RAD stuff built into .net is NOT how dot net works, it's just a tool set for getting prototypes up. .NET allows us to do full DDD applications, w/ high levels of cohesion, seperations of concerns, and allows us to write decoupled code, despite all the attemps ms makes to couple things. I would strongly disagree that .net likes to be coupled, certian tools like to be coupled, i'll include linq to sql in this fray. linq to sql destroys the idea of having a seperate domain model. I cringe at the thought of using my database schema as the underlying model objects. Proper ORM tools should allow us to model our domain first, then link our relational database to these models. NOT the other way around.
I have not tried the Entity Framework, but I definitely would recommend NHibernate over Linq to SQL; The biggest reason I can give is just the control. Linq to SQL likes to have a lot more control over everything, loading the object and maintaining all kinds of tracking information about the object. If you serialize/deserialize, the tracking information can be lost and strange things can happen when saving it again. NHibernate works more as a repository should - You hand it whatever object you want (that you have configured it to understand, of course), and it puts it away in the database, regardless of what you've done with it.