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.
Related
Recently we have decided to Tune the database of our Online Application. The database is big and having lot of unwanted objects. So as a first step in Cleaning up the Database, we decided to remove the Obsolete/Unwanted tables. We have got the list of unwanted tables in DB. Now we have to test the application run as previous only with the required tables. For that we need to make sure that the application not referring any of the obsolete/Unwanted tables. Is there any way to mark the tables as obsolete, so that application wont refer them?
One way of achiving your perpose ,i can think of , is renaming tables(add _Old to the name of table) which you want to remove. Once you run your application you can see where all its breaking. You will get a chance to decide whether to use the table or not. Once you revert the name of the table (remove _Old) it will work as earlier.
You can revoke permissions on them so the queries fail. If you have stored procedures you can look at the dependencies.
By revoking permissions to a certain table, everytime the application tries to access the obsolete table, an exception will be thrown. And there should be a record of this in the database and application logs.
I'm trying to create a Multitenant application with spring.
I'm trying to have a different schema for each Tenant on a PostgreSql database.
I first created a TenantAwareDataSource extending org.springframework.jdbc.datasource.AbstractDataSource where basically I manage a Map of org.apache.commons.dbcp.BasicDataSource, configuring setConnectionInitSqls() for each tenant. (The datasource the project had before was org.apache.commons.dbcp.BasicDataSource)
But then discussing it with a friend, we came up with the idea of changing the schema for every statment executed with an aspect (aop), simply adding a set search_path to statement just before normal execution.
This could greatly simplify the problems related to having too many connections to the database (a connection pool for every tenant at any given time).
Has anybody executed additional statements using AOP?
Any pitfalls to overcome?
I'm thinking on put back org.apache.commons.dbcp.BasicDataSource and intercept java.sql.Statements.exe*(..)
I'm not very experienced with Spring persistence. Or SQL statement execution interception for that matter (haha).
Is it ok?
I found this article but I don't think I need to obtain a reference for each connection.
Am I right?
Also found this one. The author is using org.springframework.jdbc.core.JdbcOperations. Not sure it's the case in my Spring Roo generated project.
Thank you all.
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 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
I'm not sure how to formulate that question but:
you have a webpage
the webpage got a specific user/pass in the web.config for the connection string
on a webpage you ask for a user/pass that is connected to a table (id, name, pass)
the user is recognized with a valid user/pass and now you know the id from the table above
the user change some data in a table and that table got a trigger
from that trigger, how to retrieve the user id from step 4
Let's say the user is logged using the asp.net membership table
Use SET CONTEXT_INFO and CONTEXT_INFO() to pass out-of-band parameters. Your Web layer must ensure it sets this correctly on each connection it uses prior to calling into the database, which means one extra additional round-trip to the database.
In step 4, when you say that YOU know it, what you really mean is that your application knows what user id is logged in. Your application's authentication is completely separate from your database authentication (excepting maybe using windows authentication with SQL server, but I don't think that's what you're doing).
As KM mentions, you would need to pass the application user id to the trigger by means of a "LastUpdatedUserID" column or some such thing on the table being updated.
#KM, or move your users into AD and use integrated auth. No other option here.
you need to have a LastChgID column (or similar) on the table they are changing based on the web page user/password, then INSERTED.LastChgID will tell you. otherwise, you are out of luck.
EDIT
When you save the change, store the web apps user ID into the table's LastChgID column, this may require passing it into the stored procedure, or just SET that column in the UPDATE statement. When the trigger fires, INSERTED.LastChgID will have the web apps user ID.
Since the username is just data it is tough to capture via a trigger.
Option #1 is similar to what KM said and your developer would have to pass the username via a query and update an audit column in the database. and the trigger would grab that column vlue on updates and do what ever you want with it.
Option #2 would be to programatically create the user in SQL server or your windows domain structure, give it access to the application and then impersonate that user upon entry for subsequent logins. This would be an administrative maintenance issue, but the application users would then access the database using their unique ID instead of the one configured in web.config and all updates to the database are as that user instead of the generic one supplied in web.config.
Hope this helps.
As has already been suggested (by Remus Rusanu) using the SET CONTEXT_INFO for this means you don't have to add parameters on all your stored procs to do this. A similar question from myself can be found here:
SQL Server: Modifying the "Application Name" property for auditing purposes