by Matthew Noonan
19. January 2006 06:55
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.
Subscribe