Warnings in edmx file when upgrading from 3.5 to 4 - .net-4.0

I updated my solution from .NET 3.5 to 4.0, and thanks god, I just had to fix minor things.
But what I don't understand is, the edmx file generated many warnings like this:
Error 2005: Mapping Association 'FK_CP_C' is redundant:
Its referential integrity constraint provides sufficient information.
You can safely delete the mapping information for this association.
Have you ever encountered this?
Should I do take the risk and delete the associations?
I tried to google it but wasn't able to find anything.
Thanks

Well FYI I made a backup of the project before, removed those associations thoat reported an error, updated the model, and the warnings are gone.
I missed to notice what kind of associations caused the warnings.
Hope this might help someone in the future.

Related

Why is there no initiallyDeferred parameter on Liquibase addNotNullConstraint?

Any reason why Liquibase's addNotNullConstraint doesn't have an attribute initiallyDeferred?
addForeignKeyConstraint and addUniqueConstraint both have an attribute initiallyDeferred.
I think this is just a missing feature. Liquibase has very few people contributing code, so sometimes things just aren't done yet. My company (Datical) has been making efforts to improve that, but we still rely very heavily on the users of Liquibase to point out where there are shortcomings.
I have created a jira ticket (CORE-3024) to track this.

CascadeBeforeDelete and CascadeAfterDelete

Everyone:
I've just recently finished implementing a "Soft Deleting" mechanism for my database driven web product using NHibernate. I followed the tutorial here for creating a SoftDeleteListener and it works like a charm, Kudos to the Gabriel Schenker who wrote that very good tutorial.
So, what's the problem? Well, I updated his code for the SoftDeleteListener I've implemented, and I tested it and all seems well. However, when I use a code template from a third party, I ALWAYS want to understand completely what every line of code is doing. In this case, however, I've searched and searched but I cannot find any documentation on the functions of the CascadeBeforeDelete and the CascadeAfterDelete methods! I can pretty much infer that they are doing some sort of foreign key cascading deletion functions, but the documentation on what exactly they are doing is nowhere to be found.
Can someone please point me to the proper documentation for these methods? Or, if none exists, could you kindly explain them to me?
Thanks in advance.
There's no documentation for those methods.
What you can do is get the NH sources and see how it's used in the code.
After Diego's suggestion, I've taken a quick look at the NHibernate sources for these files and, from the comment blocks in the source code, have determined their functions:
CascadeBeforeDelete - Cascades the delete call to all collections of that object before the object is deleted.
CascadeAfterDelete - Cascades the delete call to all many-to-one relationships to the object after the parent has been deleted
This was just taken from the comment directly, and I really don't have the time to thoroughly investigate these methods functions (tight deadlines keep me awake at night). If anyone has any more information on these methods they would like to share it would be greatly appreciated. Thanks.

SQL Server table-relations necessary with NHibernate?

This may be a really silly question, but I've found no answer on google/bing...
If I already use NHibernate for persistence with SQL Server, why should I then create all the table-relations on the database-schema?
I'm just wondering because it seems to create all the relations, altough I already have defined them in the NHibernate-mapping.
Best regards,
Daniel Lang
If the schema was generated via NHibernate, it already established all the relations on a schema level. Now, if NHIbernate was not used in the generation of the schema, you would still be advised to establish them, because there's always the chance that a coding mistake could lead to database operations which would break the relationship rules, but NHibernate is ignoring due to a bug in the code.
An example of this would be a relationship with a Not Null constraint. If NHibernate is configured incorrectly, it may very well try to update an object and set the relation to Null (say, instead of deleting it), which would be really hard for you to debug without the correct relations and/or an NHibernate debugging tool like NHProf.

NHibernate SQLite on Mono concurrency problem: Database file is locked

I have an application I'm porting from MSSQL and .NET to SQLite and Mono. I'm using NHibernate, FluentNHibernate, NHibernateLINQ and SQLite.
When I test the application with only one person connected everything works OK, but the moment somebody else starts using the app it breaks and throws an SQLite Exception saying "Database File is Locked".
I know that SQLite locks the database when a write is being made and returns a busy status, I'm guessing maybe I haven't configured NHibernate correctly to handle this, but I can't find any information online that has helped so far. It's like I'm the only person with this problem. Am I ? Any ideas ?
Thanks
I suspect your problem is not FNH per se.
I had a similar problem in my FNH / SQLite project (.NET, not Mono). It mysteriously fixed itself after I refactored some of the session management code for other reasons. (The main changes were to use Transactions for ALL DB access, and to ensure all Transaction and Session objects were properly Disposed).
This link discusses a similar problem that was caused by a missing Dispose. I suspect that may have been my problem, but am not sure. (Just keeping my fingers crossed that the problem does not reappear!).
Another good source of things to try is Database file is inexplicably locked during SQLite commit

Getting Started with Fluent NHibernate

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.