I'm getting back into NHibernate and I've noticed a new configuration property being used in examples: SchemaAutoAction. I cant seem to find documentation on what the various settings mean. The settings / my guesses as to what they mean are:
Recreate -- Drop and recreate the schema every time
Create -- If the schema does not exist create it
Update -- issue alter statements to make the existing schema match
the model
Validate -- Blow up if the schema differs from the model
Is this correct?
SchemaAutoAction is the same as schema-action mapping attribute.
As per docs:
The new 'schema-action' is set to none, this will prevent NHibernate
from including this mapping in its schema export, it would otherwise
attempt to create a table for this view
Similar, but not quite. The SchemaAutoAction is analogous to the configuration property hbm2ddl.auto, and its values are:
Create: always create the database when a session factory is created;
Validate: when a session factory is created check if the database matches the mappings and throw an exception otherwise;
Update: when a session factory is created issues DDL commands to update the database if it doesn't match the mappings;
Recreate: always creates the database and drop it when the session factory is disposed.
Related
I try to create a simple Hibernate example which reads some articles from a database. The following code shows me the article description from the (already existing) table Art(icle). But it also tries to create the Table "Art" if openSession is called. I just want to read from the existing table, so why it tries to create the article table before it shows the existing entries?
sessionObj = buildSessionFactory().openSession();
Query<Art> query = sessionObj.createQuery("from Art",Art.class);
for(Article a : query.getResultList()) {
System.out.println(a.getDesc());
}
Which values you use in your configurations ?
From docs you can use:
hibernate.hbm2ddl.auto
Automatically validates or exports schema DDL to the database when the
SessionFactory is created. With create-drop, the database schema will
be dropped when the SessionFactory is closed explicitly.
validate | update | create | create-drop
from this
1)validate: validate the schema, makes no changes to the database.
2)update: update the schema.
3)create: creates the schema, destroying previous data.
4)create-drop: drop the schema at the end of the session.
Hope that helps
In our test environment, the schema is prepended to the trigger DDL as one might expect. However, in our QA and PROD environments, the schema prefix doesn't show in the DDL. We always connect as the "SCHEMA" user so it hasn't been a problem thus far. Is it worth updating the QA and PROD DDL's to include the schema prefix? If we don't ever connect to the DB as a user/schema other than "SCHEMA", do we really have anything to worry about?
TEST DDL:
create or replace TRIGGER "SCHEMA"."MDATA_BIR_TRG"
BEFORE INSERT ON "SCHEMA"."METADATA"
FOR EACH ROW
BEGIN
---CODE HERE.
END;
QA DDL:
create or replace TRIGGER "MDATA_BIR_TRG"
BEFORE INSERT ON "METADATA"
FOR EACH ROW
BEGIN
---CODE HERE.
END;
I agree with omeinusch that the schema name is not that important (as long as the current schema is the same as the schema where the object is intended to reside). There is no need to recompile the trigger and make it fully qualified.
A common approach to exporting an object's DDL is to use the SQL Developer's export wizard which does allow you to indicate whether the DDL of the object is schema qualified.
Directions to obtain DDL from SQL Developer export wizard
right click on the object in the connection navigator and select export
choose characteristics of export (include schema by selecting check)
make sure file path is entered.
click next.
No, the SCHEMA is optional and only needed if you want ensure that the handled object belongs to a defined schema or not. If you "don't care" and always use mean your current schema, you can omit it.
The MSDN documentation for sp_getapplock says:
[ #Resource= ] 'resource_name' Is a string specifying a name that
identifies the lock resource.
The lock resource created by sp_getapplock is created in the current database for the
session. Each lock resource is identified by the combined values of:
The database ID of the database containing the lock resource.
The database principle specified in the #DbPrincipal parameter.
The lock name specified in the #Resource parameter.
My questions:
1. is the 'resource_name' just any old name you make up?
2. does the 'resource_name' have to refer to a table name or stored proc name or a (named) transaction name?
Yes, it's any old name you make up. You can say "sp_getapplock 'kitten'" and it will wait for the "kitten" lock to be released before acquiring it for itself and continuing on. You have to define the resources that make sense to serialize the access to.
I don't like the idea of naming the lock after a table because then it implies to other coders that access to that table is serialized when there's nothing in SQL Server (except for the applock framework) to enforce that. Put another way, applocks are sort of like a traffic light. There's nothing inherent about a red light that prevents you from going forward. It's just a good idea not to.
I've built an MVC3 application using the Entity Framework database first approach. I was able to round trip all objects, then needed to make a schema change. After changing the database schema and updating the .edmx, SaveChanges() fails for objects that map to a db table with column changes.
Specifically: Originally I had a table 'project_issue_installation' that had column 'installation_system_id'. I've changed the schema to remove the 'installation_system_id' from 'project_issue_installation', ran an 'update model from database', recompiled and checked the datmodel .edmx. No errors on compilation and the model .edmx looks correct.
When I try to persist a project_issue_installation object, I get a Invalid column name 'installation_system_id' exception.
I've searched the entire solution for 'installation_system_id' and came up with nothing. Can anyone point me to where the app is holding on to that column name?
-Dan
Turned out to be a problem in the db schema, not the EF model. My DBA missed a trigger that was still pointing to the old column.
I have an existing NHibernate 2.1.2.4000 mapping that uses the mapping syntax:
<database-object>
<create>
CREATE VIEW View_Register AS ... (truncated for example)
</create>
<drop>
DROP VIEW View_Register
</drop>
</database-object>
When the database schema gets created, I use:
new SchemaExport(_configuration).Execute(true, true, false, aSession.Connection, tw);
The third parameter in the method above is 'dropOnly', which is obviously set to false.
In the past, my schema is created and the 'View_Register' is created successfully. Now, I'm re-running the schema generation, and the DROP is called at the beginning of the schema generation, but the CREATE is never called. I've confirmed this with multiple SQL profilers including the NH profiler.
Using explicit dialect declarations doesn't seem to work either:
<dialect-scope name="NHibernate.Dialect.MsSql2000Dialect"/>
<dialect-scope name="NHibernate.Dialect.MsSql2005Dialect"/>
<dialect-scope name="NHibernate.Dialect.MsSql2008Dialect"/>
Any ideas folks?
Thanks,
David
I'm a complete idiot...
My View_Register mapping/view was completely fine, and was not my problem.
A different view was failing to create BEFORE View_Register because of a renamed table. Apparently, subsequent database-object/create calls are aborted on any ADO exception thrown by a previous create.
Good to know, but I feel silly for answering my own question!