<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>8bit Blog &#187; NHibernate</title>
	<atom:link href="http://www.8bit.rs/blog/index.php/category/microsoft-net/nhibernate/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.8bit.rs/blog</link>
	<description></description>
	<lastBuildDate>Fri, 05 Feb 2010 12:06:21 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>NHibernate 2.1 updates schema metadata without being asked to</title>
		<link>http://www.8bit.rs/blog/index.php/2009/10/nhibernate-21-updates-schema-metadata-without-being-asked-to/</link>
		<comments>http://www.8bit.rs/blog/index.php/2009/10/nhibernate-21-updates-schema-metadata-without-being-asked-to/#comments</comments>
		<pubDate>Fri, 16 Oct 2009 16:40:28 +0000</pubDate>
		<dc:creator>bdrajer</dc:creator>
				<category><![CDATA[NHibernate]]></category>

		<guid isPermaLink="false">http://www.8bit.rs/blog/index.php/2009/10/nhibernate-21-updates-schema-metadata-without-being-asked-to/</guid>
		<description><![CDATA[In NHibernate 2.1, the session factory is set up to access the database immediately when you build it. This is done by a Hbm2ddl component to update something called SchemaMetaData: I’m not sure what this is all about, but I am certain that such behaviour is not nice. The previous version of NHibernate didn’t do [...]]]></description>
			<content:encoded><![CDATA[<p>In NHibernate 2.1, the session factory is set up to access the database immediately when you build it. This is done by a Hbm2ddl component to update something called SchemaMetaData: I’m not sure what this is all about, but I am certain that such behaviour is not nice. The previous version of NHibernate didn’t do it, so I expect the new one to behave likewise unless I explicitly order the change.</p>
<p>The solution for this is to add a line to your hibernate.cfg.xml file that says:</p>
<pre>&lt;property name=&quot;hbm2ddl.keywords&quot;&gt;none&lt;/property&gt;</pre>
<p>Note that completely omitting this setting will actually <em>enable</em> the feature… Did I already mention I don’t like it? I don’t, so much that I decided not to change config files but to hardcode it disabled. I use one global method to load the NHibernate configuration, so this is easy. The code looks something like this:</p>
<pre>_configuration = new global::NHibernate.Cfg.Configuration();
_configuration.Configure();
_configuration.SetProperty(&quot;hbm2ddl.keywords&quot;, &quot;none&quot;);</pre>
]]></content:encoded>
			<wfw:commentRss>http://www.8bit.rs/blog/index.php/2009/10/nhibernate-21-updates-schema-metadata-without-being-asked-to/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>NHibernate queued adds on lazy-load collections</title>
		<link>http://www.8bit.rs/blog/index.php/2009/07/nhibernate-queued-adds-on-lazy-load-collections/</link>
		<comments>http://www.8bit.rs/blog/index.php/2009/07/nhibernate-queued-adds-on-lazy-load-collections/#comments</comments>
		<pubDate>Wed, 22 Jul 2009 12:14:45 +0000</pubDate>
		<dc:creator>bdrajer</dc:creator>
				<category><![CDATA[NHibernate]]></category>

		<guid isPermaLink="false">http://www.8bit.rs/blog/?p=32</guid>
		<description><![CDATA[I don’t know if this behaviour is documented (well, yeah, the (N)Hibernate documentation is pretty thin but it’s improving), I wasn’t fully aware of it and this caused a bug… I’m posting this in hope it may save for someone else the time I have lost today  .
In our software we use a custom [...]]]></description>
			<content:encoded><![CDATA[<p>I don’t know if this behaviour is documented (well, yeah, the (N)Hibernate documentation is pretty thin but it’s improving), I wasn’t fully aware of it and this caused a bug… I’m posting this in hope it may save for someone else the time I have lost today <img src='http://www.8bit.rs/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> .</p>
<p>In our software we use a custom NHibernate collection type that is derived from AbstractPersistentCollection and keeps track of “back references”: that is, references to the record that owns the collection. It does this automatically when an object is added to the collection.</p>
<p>Now, on collections mapped as lazy-loading, Add() operations are allowed even if the collection is not initialized (i.e. the collection just acts as a proxy). When adding an object to a collection in this state, a QueueAdd() method is called that stores the added object in a secondary collection. Once a lazy initialization is performed, this secondary collection is merged into the main one (I believe it’s the DelayedAddAll() method that does this). This can be hard to debug because lazy load is transparently triggered if you just touch the collection with the debugger (providing the session is connected at that moment), and everything gets initialized properly.</p>
<p>Our backreference was initialized at the moment the object was really added into the main collection. But this is not enough, we had to support queued adds &#8211; that is, the cases when QueueAdd returns true. The other alternative is to disable delayed adds by commenting out the places where QueueAdd is called – I don’t know if this is possible, there seems to be some code that supports it. We decided to support delayed add, and it seems to work. The modification looks something like this (this is the PersistentXyz class):</p>
<pre>int IList.Add(object value)
{
    if (!QueueAdd(value))
    {
        Write();
        return ((IList) bag).Add(value);
    }
    else
    {
        // if the add was queued, we must set the back reference explicitly
        if (BackReferenceController != null)
        {
            BackReferenceController.SetBackReference(value);
        }
        return -1;
    }
}</pre>
]]></content:encoded>
			<wfw:commentRss>http://www.8bit.rs/blog/index.php/2009/07/nhibernate-queued-adds-on-lazy-load-collections/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Supporting triggers that occasionally generate values with NHibernate</title>
		<link>http://www.8bit.rs/blog/index.php/2009/04/supporting-triggers-that-occasionally-generate-values-with-nhibernate/</link>
		<comments>http://www.8bit.rs/blog/index.php/2009/04/supporting-triggers-that-occasionally-generate-values-with-nhibernate/#comments</comments>
		<pubDate>Mon, 13 Apr 2009 17:21:31 +0000</pubDate>
		<dc:creator>bdrajer</dc:creator>
				<category><![CDATA[NHibernate]]></category>

		<guid isPermaLink="false">http://www.8bit.rs/blog/?p=17</guid>
		<description><![CDATA[NHibernate supports fields that are generated by the database, but in a limited way. You can mark a field as generated on insert, on update, or both. In this case, NHibernate doesn’t write the field’s value to the database, but creates a select statement that retrieves its value after update or insert.
Ok, but what if [...]]]></description>
			<content:encoded><![CDATA[<p>NHibernate supports fields that are generated by the database, but in a limited way. You can mark a field as generated on insert, on update, or both. In this case, NHibernate doesn’t write the field’s value to the database, but creates a select statement that retrieves its value after update or insert.</p>
<p>Ok, but what if you have a trigger that updates this field in some cases and sometimes doesn’t? For example, you may have a document number that is generated for some types of documents, and set by the user for other types. You cannot do this with NHibernate in a regular way – but there <em>is</em> a workaround…</p>
<p>It is possible to map multiple properties to the same database column. So, if you make a non-generated property that is writable, and a generated read-only property, this works. You have to be careful, though, because the non-generated property’s value won’t be refreshed after database writes.</p>
<p>A more secure solution would be to make one of the properties non-public and implement the other one to support both functionalities. Like this:</p>
<pre>//
// This field is used only to send a value to the database trigger:
// the value set here will be written to the database table and can be consumed by
// the trigger. But it will not be refreshed if the value was changed by the trigger.
// </summary>
private int? setDocumentNumber;	

private int? _documentnumber;

//
// The public property that works as expected, generated but not read-only//
public int? DocumentNumber
{
	get { return _documentnumber; }
	set
	{
		// NHibernate is indifferent to this property's value (it will not
		// be written to the database), so we have to update the setDocumentNumber
		// field which is regularly mapped
		_documentnumber = value;
		setDocumentNumber = value;
	}
}</pre>
<p>Here’s the NHibernate mapping for these two:</p>
<pre>&lt;property name=&quot;DocumentNumber&quot; generated=&quot;always&quot; insert=&quot;false&quot; update=&quot;false&quot;/&gt;
&lt;property name=&quot;setDocumentNumber&quot; column=&quot;DocumentNumber&quot; access=&quot;field&quot;/&gt;</pre>
]]></content:encoded>
			<wfw:commentRss>http://www.8bit.rs/blog/index.php/2009/04/supporting-triggers-that-occasionally-generate-values-with-nhibernate/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
