Ayende @ Rahien

Ayende Rahien commented on Append Only Models with NHibernate

Thu, 17 Sep 2009 19:53:50 GMT

Chris, I do that in the message module

Chris Nicola commented on Append Only Models with NHibernate

Thu, 17 Sep 2009 15:37:21 GMT

Oren, sorry if this is a little off topic but I am curious how the transaction (and perhaps the session) is handled by the infrastructure in a case like this. I am doing something that looks very similar. A message is passed and the consume() method changes something in the domain. For me the session and transaction are opened and closed by the consume method. I'm sure there is a better approach than opening a session each time consume is called. I also don't like my message handler having a dependency on SessionFactory.

Frank Quednau commented on Append Only Models with NHibernate

Wed, 16 Sep 2009 17:07:59 GMT

liviu, row version snapshots? we are not using this feature in any way...considering that we are doing this mayhem on an Oracle Database it would make it pretty difficult, too :)

Steve Py commented on Append Only Models with NHibernate

Wed, 16 Sep 2009 01:27:19 GMT

Yeah, I definitely don't want to break it. After further work with the problems over the last couple days there aren't any show-stoppers with managing FK between objects. Whether those are updated to new versions or not is the responsibility of the application(s). Trying to automatically "change" those references behind the scenes would be a painful exercise. But I do want to be sure that when I go to fetch data based on search criteria (that hasn't necessarily changed with the revision) that I get back the current reference, not a cached copy of a potentially stale object. I can see how you might address that with the lastest version table, however I'd like to see that applied with mapping/DAL-isms. Using fetch by example for instance with the FK2Ancestor I need to tell NHibby to ignore fields like Revision/Version as I don't know what the latest version is. Using Linq2NHibby I've resorted to SortDescending + FirstOrDefault. With FK2Descendant I'm interested in rows that have no descendant unless I explicitly state otherwise. (or pull references by ID for historical associations) I *think* I can trigger my app to ensure that Descendant isn't present so that when my descendant reference is refreshed due to a new replacement I can dump the object and reload it to get the current revision. Heh, I'd love to hook up NH Prof to it just to see what's really going on behind the scenes. It *does* work, but... But I'm dealing with a relatively small data pool and I don't want this biting me in the ass when dealing with larger databases if this turns out to be doing more than index scans. (I guess SQL Prof can tell me that...) *sigh* This pot just keeps boiling over with more stuff to try...

Ayende Rahien commented on Append Only Models with NHibernate

Wed, 16 Sep 2009 00:28:09 GMT

Steve, The problem with trying to refresh to the same instance from different version (which is actually a different row) is that you are missing the issue of the PK to instance mapping (identity map). NH is built around the idea of identity map, and you won't get far trying to break it.

Steve Py commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 23:08:35 GMT

@Dave - That's a snapshot more than append-only. It's perfectly suited to audit history tracking. One goal of append-only models is that references to previous revisions of data can be maintained, while new data references current revisions. As Ayende pointed out regarding his Contracts example. Along with Ayende's example there is the option to use FK-2-Self references to ancestors or descendants. The benefits of these approaches is that you avoid combined keys. FK-2-Ancestor works well with NHibernate, though there is a bit of work needed if you want to archive records at a certain cut-off point. (Need to clear a FK off the new tail, and then take steps to merge back into the chain when that record itself gets dumped to the archive.) FK-2-Descendant handles the archiving scenario a bit more gracefully (needing only a proxy in the archive that is overwritten) but doesn't keep ancestry "pure" from updates as ancestors need to be updated with associations to their new descendants. In any case there still appears to be a bit of baby-sitting needed in applications to ensure that the latest revision of a given object is maintained, and in my experience NHibernate's caching can be a bit of an obstacle. My question to Ayende is what techniques might be employed with/around NHibernate to detect, and refresh revisions to objects? I'm thinking that FK-2-Descendant may have a benefit because it "dirties" the record when it is replaced...

Ayende Rahien commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 20:11:38 GMT

Liviu, Huh? Why would it be a problem for read committed? I can see it being a problem for repeatable read or up, but read committed doesn't lock rows it reads.

Ayende Rahien commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 20:09:07 GMT

Scott, That would just make NH not save them. I want to force an error if you try

Ayende Rahien commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 20:03:12 GMT

SteveoReno, I often hear this, but it tend to fail in real life. Too leaky an abstraction

Ayende Rahien commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 20:02:29 GMT

Kurt, ChangeMaritalStatus will return a NEW INSTANCE of the employee, there is no update going on.

Ayende Rahien commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 20:01:32 GMT

V, That requires that you would still update things, and that violate the append only model. That type of behavior is for audit trails, not append only. I think I have a post about how to implement those.

Ayende Rahien commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 19:59:31 GMT

Rafal, I explicitly stated that this model requires a reporting model to do most queries from. I didn't touch references because they just work, but I guess that I should have explicitly mentioned that each entity is a _point in time_. Its references are also to a particular point in time. It doesn't make sense to be able to update an entity association without also updating the entity in those type of models. A good example would be with contracts. I may update the contract, but the employee's employement contract doesn't change because the contract was updated. There is an explicit step required to change the employee from one version of a contract to another.

liviu commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 19:49:08 GMT

@Frank Quednau: row version snapshots in sql 2005+ put a heavy burden on tempdb in oltp scenarios but are generally ok for reading data. In mixed read/update scenarios in a transaction they are useless because you check db constraints against stale data.

SteveoReno commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 18:48:48 GMT

I would expect the append only to intercept 'update' calls where the object exists and perform an 'insert' instead. That is what I consider 'append only' And with a, ie., one to many relationship, each object in the object graph would need that logic. Too bad this can't just be set in the mapping files...

Kurt Harriger commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 17:18:16 GMT

I would be very interested in learning more about implementing the append only model with NHibernate. I could envision the GetLatest extension method, but my understanding the

Scott White commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 16:21:46 GMT

Why not just set mutable to false?

Ollie Riches commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 16:10:00 GMT

@Daniel Auger I currently 'live' in such an environment :(

Daniel Auger commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 15:59:45 GMT

@Ollie. I do agree on all points you have there :)

Ollie Riches commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 15:53:34 GMT

@Daniel Auger That's not an acceptable way to do 'Goldern Source'... It's an excuse from the same book as 'This is to complicated to write tests'... it's also a sign that DBAs have to much control over the development process...

Daniel Auger commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 15:39:53 GMT

@Ollie - 7 applications using the same DB is laughable to many developers, but you have to remember that "one true database" is still the mantra in DBA circles.

V commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 14:40:55 GMT

On other way of doing this is instead of inserting the newest Employee you update the current and insert the Old... this way you keep all the references. 2 changes to the database but not having to worry about updating FKs references is a bless. public void Consume(ChangeMaritalStatus msg) { var emp = Session.GetLatest

Eyston commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 12:22:42 GMT

I can't imagine going to a composite key model by choice. I used one for the past year with NH, and while NH makes it work, it is not a good experience. The cool stuff starts to happen when you have multiple consumers of ChangeMaritalStatusMsg. I must say I'm eager to try out Domain Event style programming that leads to multiple, specifically targeted data stores.

Mr_Simple commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 10:40:22 GMT

@Dave Mertens Now that is a pattern Mr_Simple gives gold stars for, so one gold * for you.

Frank Quednau commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 09:18:28 GMT

Our current project is pretty much an "Append Only" application. Here, all relevant "Objects" carry an object state, either current, under revision or obsolete. Finding the latest object is a matter of saying "select from x where id = y and state = current". However, this leads to one update of the previous current, which becomes superseded. Also, the application must take care of updating fk references /inserting new ones (for m:n relationships) between objects since currents may only reference other currents. Either way, this is a very special domain, since we are also forced to do denormalizations as superseded objects must remain completely frozen in their state. We are doing this very DB-centric (speak DataSets) for mostly non-technical reasons, which is why I was looking forward to this post. One day I'd love to see how this could have been done with NHibernate, but that's a pleasure I'll have to set up myself..:)

chrisb commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 08:59:51 GMT

@liviu: Its been a while since I read up on any of this stuff, but would enabling and using row version snapshots in sql 2005+ get you out of that particular hole without really needing to change much?

Ollie Riches commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 08:42:00 GMT

@Dave Mertens 7 applications that use the database! ROFL....

liviu commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 07:46:22 GMT

..And of course, all writers to the same entity type will be SERIALIZED

liviu commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 07:41:29 GMT

Hi, SELECT * FROM Employees WHERE Id = 12312 and Version = ( SELECT Version FROM LatestVersions WHERE Type = 'Employees' AND LatestVersions.Id = Employees.Id The aggregate table with Latest versions is a disaster for long running update transactions... every reader of latest versions will be blocked if using read committed transactions... We have come to a workaround for this, but i would expected you to have seen the big problem ...

Dave Mertens commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 07:12:30 GMT

We have a totally different approach to append only tables. Each table also has a 'history' table to holds the previous versions. Records are moved to the history table by triggers. Each record also contains the database user who issues the update (part of the audit trail). NHibernate does not have a clue about the append-only model. Our databases are used by multiple applications so in my humble opinion the database should now these business rules and not the 7 applications that use the database. I don't want to think about the problems I would face if these rules were part of each application and a new application doesn't follow the append-only model rules and issues a delete statement.

Rafal commented on Append Only Models with NHibernate

Tue, 15 Sep 2009 06:33:02 GMT

This model is good if you want to know previous versions of data, but it's not optimized for most typical uses like access to current status and querying. Steve's question is very important - you didn't touch the subject of joins and many-to-one/many-to-many references. In your model you would have either to update the references in all referring objects on each version change or to do some tricks with joins to get the latest version of referred objects. None of these is supported 'out of the box' by NH and requires manual work. I would rather build a normal read/write data model and use append-only where it is strictly necessary (where business requirements state clearly that we must store previous versions).For all the remaining updates I'd build a 'history' table where each field modification would be stored. This could be done automatically using update triggers (either database-level or in the ORM).