| 8/14/2007 7:57:24 PM |
Hi!
I would like to know the following.. I have a regular string column Apple.Color in database (which is NOT NULL and has a default value set to "").
So the class for that table that gets generated has a member:
string color;
and a corresponding property. By default this value is null and doing this
Appel apple = (ProfileStatus)Manager.GetObject(typeof(Apple)); apple.NumberOfWorms = 3; Manager.PersistChanges(apple);
Will throw an exception, because apple.Color == null and database doesn't allow nulls. The only reasonable workaround is to explicitely say apple.Color = ""; before persisting the changes.. I'm not sure how beautiful that approach is though.. is there no way that generated classes would set the value to a deafult value as in database?
Thank you for the answer!
David
|
| 8/16/2007 7:34:10 PM |
Hi! I actually tried nullValue="", but it didn't change anything.. As far as I can see that only influences *reading*- so if the null value is already in the DB and I read it, I will magically see it as "". It didn't work for this case. So when trying to save NULL to the DB, it still generates an exception and is not converted to "" beforehand. Can you confirm that? So is nullValue just for reading - writing doesn't pay attention to it, it seems!? THANK YOU!
I see.. I can set the member to "" in a class. I was reluctant to change the generated code, because I thought I will generate it again if the database changes so much that it's better to do it that way instead of adding things manually... But you explained what's the philosophy with this in an email.. I'm posting it for the others: Hi David:
Sorry, but there is no one best practice or right answer here. It comes
down to your software methodology and even your own style.
There are methodologies that use extensive code regeneration. But they are
typically very strict metholodogies to make sure you both don't lose the
custom changes you do make and to minimize the need for those. The ORHelper
is definitely not a tool that will work in that type of methodology. Why?
Because it was simply never designed or intended to be anything more than a
quick and ugly start. I did not feel that delivering the ORMapper without
any "helper" to get people started was good enough, but Nhibernate succeeded
quite well without such a "helper". Why? Because a good O/R Mapper in no
way depends on such "helpers" -- thus my users made their own CodeSmith
templates, as did Nhibernate's users, and many rely on doing things manually
since the whole point of an O/R Mapper is your custom objects, plus a little
xml glue. Can a strict code regeneration methodology use an O/R Mapper?
Sure, but they will use flexible and customizable CodeSmith templates, and
while some of the ones my users have provided may help, you'll also find
you'll need to customize them to really do that right. This is really a
whole subject all its own -- i.e. there is at least one book I know of on
code generation methodology, and there are many consultants and tools out
there. The ORMapper on the other hand is simply a consumer of your code,
and how you produce your code is of course up to you.
I'm not personally into code regeneration. Why? I've been around it just
enough to know that it either doesn't work well, or requires extensive
methodology that is strictly followed.
Thanks, Paul Wilson |
| 8/17/2007 1:46:10 AM |
Oops. It does do "something" for both reading and saving, but not what I said. The nullValue setting is what nulls in the database get converted into, and similarly that value gets converted back to null when saved to the database. That's of course not what you were wanting at all, as you don't want nulls in your database, so the second option is by far the best I can think of.
So what is nullValue for by the way? Its for value types that cannot be null in code, but can be null in the database. And that's not necessary if you're in .net v2 since you have nullable types.
Sorry, Paul Wilson |
| 8/22/2007 8:18:42 PM |
Thank you Paul. That's great and everything is clear now. |