It was bound to happen sooner or later, but as the weeks went by and I kept one eye on my email and the other on the MyGeneration forums, I started to entertain the thought that maybe there just weren't any bugs in EO 1.0.

Alas I was, of course, wrong...  <sigh>

User "daveyjclark" discovered that if an error is thrown during the Save operation, the internal data operations are not properly cleaned up after the exception. This is only a problem if your object has lengthy lifespan, and you attempt to re-run an operation after an exception, but it's a very valid scenario in a Windows application (less so for web apps).

You can see the details and the suggested fix in his post. I will be incorporating these changes into the next release of EO, which is coming along quite nicely.

I have been fighting it for some time now, preferring to keep the download process simple and easy. The business reasons for doing this are many, and I understand the reluctance some of you will have to sharing your personal information. But the bottom line is: this is a necessary change in order to keep the product moving forward.

This new process follows the same model used by DotNetNuke (www.dotnetnuke.com). If you have any concerns, please read our privacy policy.

I just wanted to let everyone know that last night, EasyObjects crossed the 10,000 download mark (the combined results of our 3 download locations).

All of us here at NCI are honored and humbled by the reception EO has gotten over the last 5 months. Yes, it's hard to believe that this site was only launched in late August of last year, with the first CTP version of EO.

Thanks again for including us into your development toolbox. The development staff is hard at work on the next version, as well as picking apart the 2.0 release of the Enterprise Library.

I will post more on that soon...

As promised, the Microsoft Patterns & Practices team has released the Enterprise Library 2.0. This release is designed to take advantage of the new features found in .NET 2.0, and has been greatly anticipated by the community.

Since these application blocks are an important basis for EasyObjects, you can be sure the development team will be checking out the new release and figuring out how to incorporate the changes. This is a great step forward for the EasyObjects platform, and everyone here at NCI congratulates Microsoft on another milestone acheived.

Tom Hollander's blog entry:
http://blogs.msdn.com/tomholl/archive/2006/01/20/515526.aspx

Download the Enterprise Library
http://msdn.microsoft.com/library/?url=/library/en-us/dnpag2/html/EntLib2.asp

It's only been a couple of days since I published the roadmap, and already I'm changing it.  :(

The dilemma is this: database default values. My goal was to give EasyObjects a way to avoid sending columns that contained a NULL in the object but had a default value defined in the database. This cuts down on the amount of data that has to be transferred over the wire, but the column still gets a value because the database server will insert the default value.

Sounds good on the surface, but here's the problem. Suppose you have a simple business object with the following rows:

'Matt', 'USA', 1
'Mike', NULL, 0
'Justin', 'UK', 1

Now, if the 2nd column has a default value defined, it would be nice not to have to send the NULL and instead let the database insert the default value. Here's where it gets tricky. EasyObjects only defines one insert query for all the rows in the object (i.e., they all call the same insert proc or query). So while I could exclude the 2nd column parameter from the query, it would exclude it for all rows, effectively losing the data for rows 1 and 3.

Not an acceptable solution.

Also not acceptable (to me), is to reverse engineer the default values from the database and into the data layer. Database defaults can be anything from intrinsic values to user-defined functions. Trying to transfer that to the data layer sounds like a Pandora's Box to me. In addition, you still end up transferring the data across the wire, so I don't see the upside to this approach, but I do see a huge downside.

The only other way to tackle this problem is to redesign the Save logic to build individual queries for every row, and I'm not prepared to do that for version 1.1. I'm afraid this feature will have to be pushed back to version 3.0, when I do the ground-up redesign.

Tom Hollander just updated his blog, and it looks like there will be a release of the Enterprise Library for 2.0 by the end of this week.

Now the fun really begins!  :)

I apologize for the delay in getting this together. The holidays were very busy around here, and I needed some downtime before I could dig in to the upcoming work. Here is my current plan for EasyObjects development.

EasyObjects.NET version 1.1
(due early Q1 2006)

• Support for Insert, Update and Delete operations without the use of stored procedures. This is important for incorporating database engines that do not support stored procedures, such as early versions of MySQL, VistaDB, MS Access, etc.
• Support for aggregates in dynamic queries.
• Ability to exclude data columns that have a defined default. This can help cut down on network traffic and allows the database to perform this function.

EasyObjects.NET version 2.0
(due end of Q1 2006)

• Support for the Enterprise Library 2.0
• Very few new features, just a quick release to be able to run under .NET 2.0

EasyObjects.NET version 3.0
(no projected date)

• Ground-up rewrite of EasyObjects in order to take advantage of everything that .NET 2.0 has to offer, including (but not limited to) generics and object datasources.

Your comments and observations are welcome.

From Mike Griffin:

"This version is a patch to address a bug that was forcing output files to be written in UTF8 format where before the encoding was being chosen based on the content of the text itself. Mostly like you never noticed this change as this doesn't cause problems in most cases.

This has been fixed."

Download your copy here:
http://download.mygenerationsoftware.com/mygenV115.exe