I am currently thinking about implementing an application with NHibernate and I would like to be able to solve concurrency issues by showing the user which fields have changed since he retrieved the instance. So the user should have the possibility to compare his entered values with the one in the database and then decide which ones to use.
From what I have read NHibernate throws an Exception when stored information is persisted and the version field is different to the value in the database. Does this exception include some kind of information about the object in the database or do I have to query the database again to get the data object and compare it with my user manipulated object?
Maybe someone has already done something similiar and wants to share the code.
If you're doing this inside the same session, maybe this can help you
Related
In my code I am trying to check if my entity framework Code First model and Sql Azure database are in sync by using the "mycontext.Database.CompatibleWithModel(true)". However when there is an incompatibility this line falls over with the following exception.
"The model backing the 'MyContext' context has changed since the database was created. Either manually delete/update the database, or call Database.SetInitializer with an IDatabaseInitializer instance. For example, the DropCreateDatabaseIfModelChanges strategy will automatically delete and recreate the database, and optionally seed it with new data."
This seems to defeat the purpose of the check as the very check itself is falling over as a result of the incompatibility.
For various reasons I don't want to use the Database.SetInitializer approach.
Any suggestions?
Is this a particular Sql Azure problem?
Thanks
Martin
Please check out the ScottGu blog below:
http://weblogs.asp.net/scottgu/archive/2010/08/03/using-ef-code-first-with-an-existing-database.aspx
Here is what is going on and what to do about it:
When a model is first created, we run a DatabaseInitializer to do things like create the database if it's not there or add seed data. The default DatabaseInitializer tries to compare the database schema needed to use the model with a hash of the schema stored in an EdmMetadata table that is created with a database (when Code First is the one creating the database). Existing databases won’t have the EdmMetadata table and so won’t have the hash…and the implementation today will throw if that table is missing. We'll work on changing this behavior before we ship the fial version since it is the default. Until then, existing databases do not generally need any database initializer so it can be turned off for your context type by calling:
Database.SetInitializer<Production>(null);
Using above code you are no recreating the database instead using the existing one so I don't think using Database.SetInitializer is a concern unless you have some serious thoughts about using it.
More info: Entity Framework Code Only error: the model backing the context has changed since the database was created
I was given a pre-created project that uses Hibernate and was asked to add some features to it.
The database it came with has a user table and there is a login servlet page that uses hibernate to log in a user with provided credentials.
To get the very first user in the DB I manually INSERTed it with an SQL tool. Now when I try to log in using those credentials it fails. Is there anything extra I need to do to be able to use that manually added user?
No, to read existing data, there's nothing that needs to be done to the row itself in the database to make Hibernate read it. Your problem is one of a myriad of other possibilities, such as your Hibernate being configured to read from some other database or table, or encountering an error that you need to go find in the log.
So, I need to synchronize two data stores, one of which is a SQL database, and I felt it was natural to use the built in provider for that side. But unfortunately, I started running into trouble because the SqlSyncProvider doesn't use the ChangeDataRetriever and NotifyingChangeApplier, but instead communicates through some DbSyncContext object. Therefore, I had to derive from the SqlSyncProvider and override mainly the GetChangeBatch and ProcessChangeBatch methods so they become compatible with the rest of the Sync Framework.
But the trouble is that I believe that I'm missing something in that transformation. The result is that when I create a row in a SQL database, and synchronize to the other store, and delete the row (or update) in the other store, after syncing the changes don't appear in the SQL database. The problem is probably caused by the bulkdelete stored procedure which filters the delete table and separates rows that are created locally from the rows created elsewhere.
Does anybody know what could cause this problem? I would really like to see some samples or documentation regarding synchronization between a SQL provider and a custom provider.
At the moment I define the connection properties in a configuration file and only ever connect to one database. I'd like to be able to at some point have a user login, figure out (via a seperate central database maybe) what database they should be connected and from that point on all sessions created will talk to that database.
Whats the best way to achieve this. Create a configuration file for every possible database? Or could I have a single session manager and change the connection url on the fly accordingly? What sort of options do i have?
Update: Apologies I should have mentioned this was NHibernate. I didn't think it would matter but some things like Hibernate Shards will not be applicable to be as I believe NHibernate Shards is waiting.
You just need to make two datasources then call the one you need for the specific query.
Please take a look at this:
https://www.hibernate.org/450.html
Some official solutions.
And here:
http://www.java-forums.org/database/159-hibernate-multiple-database.html
an online thread about this issue.
I am creating an application in which i am using stored procedure where i m implementing my logic.
Now what i need to know is that- i want my database not to contain any invalid entry, for this purpose should i create triggers, for implementing my data validation logic such that when FailPasswordAttemptCount is changed to some value then should i make changes in corresponding column IsLocked accordingly thru triggers or leave it on dba to manage.
eg
if FailPassowrdAttemptCount > 3
IsCaptchaActivated=True
if FailPasswordAttemptCount>6
IsLocked=true
now if a dba changes the value of FailPasswordAttemptCount to 4 without changing IsCaptchaActivated to true then this will make an invalid entry for my frontend.
SO should i manage it thru triggers or should i left it over dba to make correct entry.
Although this type of entry is not possible thru frontend but in case any1 having privilages to access database, changes directly thru database.
For this should i leave it on user or should i manage thru triggers.
I want to make my database to remain consistent in all circumstances.
I'd make the following:
Put the data validation logic into a stored procedure
Made the stored procedure the only way the application interacts with the table
Put the code you want into the stored procedure.
Trigger-based programming paradigma grows too hard to code and maintain as the business logic complexity of your application increases.
However, if you are absolutely sure you will only have the simple logic like this, it is OK to put it into a trigger since this will require minimal changes in the ways the application interacts with the database.
I wouldn't use a trigger for something like this. Triggers are obscure and can be hard to debug for the developer. Use your tables and stored procedures to deal with the issue. Use triggers for when you don't have an alternative.
I would use a combination of both. I will try to restrict data as far as possible. And will fire trigger, so that no one can insert any invalid entry.
For this type of situation, I would probably not use a trigger, just for the situation you describe. Though I would wonder why you have dba's manually altering data in a field that closely tied to the security of your app.
I would implement this in the application logic. When calling the login sproc you can return both whether it succeeded as well as the number of failed password attempts and if captcha is needed. Regardless of if the DBA changes the 3 to a 4, your code will see the 4, ignore the result of the validation and present the user with a captcha. If you're worried about DBA's modifying the code directly you can also check the APP_NAME() function/variable to see what program is trying to modify the data. Its something to be very careful with but so is DBAs modifying fields directly.