Well, that’s why it *is* open-source…feel free to change the behavior as much as you feel you need to for your own situation

Glad you got it working satisfactorily for you!

-Steve B.

And Yes, you are right that permitting the properties to be read only is good but I think it is better to speed up the system instead

Thanks for the help, It was really helpful

Greetings from Bulgaria

Sorry I didn’t reply to this sooner — somehow I missed your comment in my rss reader. The intent was that you would use reflection in the event listener implementation to set the values of the underlying fields in the class for those read-only properties.

Yes, its got some (minor) overhead vs. setting the property directly, but IMO this is a better strategy than permitting these properties to be read-write on the domain entity.

Hope this response finds you in time and sorry for the delay~!

I have a question about the UpdatedDateTime and UpdatedBy. I implemented ISaveOrUpdateEventListener but I want to ask you whether we can do something global. So we can have only one implementation. The problem is that these properties are read only.

Greetings from Bulgaria

Well, I will go trough the nDbUnit’s code and If I can handle postgre then I will rename all 1000 rows and tables with small caps/letters But server Explorer is now running with small test table I hope I get the code and write a patch

Oh, and one more thing — as you can see from this issue on the NDbUnit site ( http://code.google.com/p/ndbunit/issues/detail?id=13 ) there is some issue with its OleDb infrastructure not working with other than SQL Server (yeah, its a screw-up to be sure) so even if you could get the dataset issue solved, you wouldn’t be able to use NDbUnit (or Proteus) with PostGreSQL until this was resolved (or until I — or someone else! — writes a shim for PostGre for it.

As with most OSS projects, patches are welcome when accompanied by requisite unit tests

-Steve B.

The database-related behavior of the Proteus library is tightly-dependent on NDbUnit which in turn is dependent on datasets as the persistence mechanism for the test data it loads/resets/etc.

A few questions:
1) what troubles (specifically) are you having with postgres + server explorer?

2) If you cannot conn to the DB using server explorer (to create the XSD for the dataset) have you tried using MyGeneration to generate the XSD for you (perhaps better luck at connecting to postgres from there)?

3) If datasets/XML weren’t to be the persistence mechanism for the test data to load/reset/etc., do you have any suggestions for any alternate file-based persistence mechanisms that might be used in their place? (obviously for the Proteus database facilities to have any value, they need to be able to load persisted data into the DB on command).

Thoughts –?

Q:Is it possible to use Proteus.Utility.UnitTest and load data without using datasets? Because I have postgre server and I have big problems connecting server explorer with that server.

Thanks Steve

Sure. The intent had always been to dig into those aspects when I completed the Autumn of Agile screencast series, but that’s still delayed so I’ve no problem explaining the intent here…

LastUpdatedBy and LastUpdatedDataTime are properties that the base class provides for NHibernate event listeners to populate on Save/Update actions performed on the objects.

Although I didn’t get that far (yet!) in the screencasts, NHibernate provides a rich persistence eventing model that permits you to ’step in’ at various points in the CRUD lifecycle and the intent was to wire up an event listeners that would populate these properties right before the object is committed to the database on either an INSERT (save) or UPDATE (update) operation. FWIW, the interface needed to be implemented is ISaveOrUpdateEventListener (not surprisingly!).

The intent if IsTransient is to solve the ‘problem’ of not wanting to expose the ID of the persistent object outside the domain entity (or more importantly, the ‘meaning’ of the ID property outside the domain entity). Rather than code outside the entity having to inspect the ID of the entity and compare it to some ‘known uninitialized value’ (e.g., ‘0′ if an int/long or ‘0000-0000-0000…etc’ in the case of a GUID), the IsTransient property permits the object itself to encapsulate its understanding of how *it* can know if it’s persistent or transient and simply report that fact back to the outside world as a boolean FACT. In this way, the code consuming the object (that might care if it’s persistent or transient) doesn’t have undue intimate knowledge of HOW to determine that fact but instead just asks the object the question and gets an answer in the form of the IsTransient property.

Does that all make sense…?

can u explain the purpose of the LastUpdatedBy, LastUpdatedDateTime and IsTransient and the more important how they actually work. I did not find any tests for these fields/props.

10x