Interesting question. Interesting in that it made me realize that I have never had a need to do this. I think that any time I am allowing nulls in string fields the app doesn't really care whether they're specifically nulls or not. So I just accept the default of "" and it hasn't caused any problems for me.
Just to satisfy my interest, can you give me an example of a use case where it matters to your app whether the value is null or "". In terms of a value to use, it doesn't really matter what you use, as long as you're using Transfer's null-support methods. That value, "[[BOOHOOHOO]]" in your example, isn't ever going to get written to the database. And if you want to check to see if a property is null, you wouldn't check for "[[BOOHOOHOO]]", you'd just check getXxxIsNull(). That's where the default value of "" comes in handy; it allows you to do things like <cfoutput>myObj.getXxx()</cfoutput> without having to check getXxxIsNull() first. I suppose that's why I've always just kept the default. Cheers, Bob On Wed, Feb 11, 2009 at 8:47 AM, barry.b <barry.beat...@gmail.com> wrote: > > these are for sentinal values so I can maintain nulls > > -1 for bool, Jan 1 100 for dates, etc. > > but if "" is a valid value, suggestions on a suitable value to > represent NULL for a string? > > somehow "[[BOOHOOHOO]]" (or similar) doesn't quite rock my socks... > > > > -- Bob Silverberg www.silverwareconsulting.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
