This has come up before here, and I still don't understand the confusion. A boolean value can be true or false. That's all.
If it's a Boolean (in Java), then it can be true or false. The reference to the Boolean might be null, but in that case, it's not a valid reference to a Boolean.
If it's SQL, a boolean still only has two values, true or false. Null is not a boolean value, any more than null is a string value. A null indicates the complete lack of a value. It's unknown/missing/whatever. Null is not a boolean value, anymore than it's an integer value.
The PostgreSQL documentation agrees with this:
boolean can have one of only two states: "true" or "false". A third state, "unknown", is represented by the <acronym style="font-style: italic;" class="ACRONYM">SQL</acronym> null value.
Jorg
@Jorg
Best posts made by Jorg
-
RE: Overheard in the next cube
-
RE: Overheard in the next cube
"Null is not a boolean value, any more than null is a string value." <- Agh. I deleted that line. Sorry for the repitition. Looks like the forum software bit me.
-
RE: Overheard in the next cube
There is no default constructor for Boolean, so it's a compiler error.
Latest posts made by Jorg
-
RE: Does Agile work for standard software development
I hate this forum software. It just ate my post.
Summary:
If you've got bad programmers, nullify them or make them better (both can be hard, I know).
Traditional big-design-doc methodologies clearly aren't working to make poor programmers produce good code. Agile methodoligies won't either. I think it's impossible to get good code from poor programmers. You'd do better to have them sit in the corner while the above-average programmers do all the work.
I agree that it is hard to hire good programmers. I blame the schools. (Seriously.) -
RE: Rational agrument against Hungarian notation?
@Hubert Farnsworth said:
Try naming a class "Controller" there and it'll propose
"ontroller.[h|cpp]" as file names. Sick.
Blech. That's some really obnoxious behavior.
Prefixing classes with C makes no sense. (I'm gusesing that) Microsoft only did it to avoid naming conflicts (since they either chose not to use namespaces or they weren't yet available). And of course, now Microsoft alone has three different CString implementations. Not to mention the million other CString implementations in other libraries/frameworks.
-
RE: Win32 C - append Url to path
@Angstrom said:
You'll need a transformation that mangles slashes:
char mangle_slash (char c) { if (c == '\\') return '/'; return c; }
std::string path = "C:\\Windows\\"; std::string fragment = "www.example.com/foo/bar"; std::string output = path; std::transform (fragment.begin (), fragment.end (), std::back_inserter (output), mangle_slash);
Completely untested. I've probably goofed up the back_inserter or the forum formatting.
He said he needs to use C, but your basic logic works.
Replacing every character seems an odd way to do a simple replace, though. It's kind of odd that C++ has a transform, but not a replace (in string). Again with the over-engineering.
-
RE: Does Agile work for standard software development
@sniederb said:
How does the development team KNOW if they're going to meet the
delivery date? They'll know around Sep 15, but what about in March 06?
Then, they obviously haven't yet specified what to do in iterations
happening in the summer (otherwise they wouldn't be embracing change),
so essentially they don't yet know what they'll be doing a month from
then.
Now the project manager asks:
- how much work is already done (%)
- are we on track for the delivery date?
In a similar vein, how does any development team ever KNOW if they're going to meet a date? Answer: They don't. Software projects are chronically over budget and past deadlines, because they cannot know when they'll be finished. Instead, they make estimates. This is the case whether the team is using agile methods or traditional methods. A significant part of XP (for example) is dedicated to learning how to better estimate time required to complete tasks. So while XP can't magically guarantee a delivery date, it aims to provide better estimates than traditional methods.
@sniederb said:Take the four variables of XP. If one of the large customers adds
scope, and the team stays the same (and - usually - quality is a
given), then it can only be time which changes. So, does EACH new
requirement prolong the developement process? Does agile mean you gain
flexibility by getting rid of a binding delivery date?
Yes and no. Yes, adding requirements extends the development process. That's just a fact of life, no matter what development process you use. Agile methods can't change that. They can, however, allow you to substitute functionality, basically for free. If you decide that you don't really need feature A, but feature B is vital, you can substitute the (unimplemented) feature A for feature B, assuming of course that they are approximately the same complexity.
In a very similar vein, agile methods allow you to leave certain features ill-defined
until later, with the understanding that a certain amount of time is
allocated to the to-be-clarified features. Of course, leaving enough
time for a simple search and then deciding that you want google
rewritten for this "simple search" is not going to work. Again, you
have to make estimates about what you're going to want; have a general
idea. This isn't precise, but it's better than locking yourself to a
design document and then realizing that the document captures the wrong
functionality. Basically, it allows you to set the scope for a feature without defining the specifics of that feature.
@sniederb said:I'm coming to believe that a software development process applies to
the first 60% of project time, while everyone's still relaxed. When the
late changes start coming in, the binding delivery date is looming and
the bugs just won't go away, it's the time for the GOOD developers to
step in and do their thing. And that is usually not very structured,
but more like sophisticated code-and-fix.
I'd have to agree that this is somewhat true. But that's exactly why agile methods exist. They aim to minimize the problems caused by changes, and maximize flexibility. The last part of development shouldn't be hack-and-go. It should be as thought-through as everything else. That's one of the promises of iterative cycles. Every cycle is as important as the ones before. So the last cycles shouldn't be hacked together. They should be of the same quality as the first cycles.
@sniederb said:A good software development process ensures that the first 60% are so
efficient that above scenario simply doesn't come up? I believe there
is no process to prevent a change request 4 weeks prior to delivery
except telling the customer you won't do it. And too me, that's really
a major thing. This isn't about internal processes, but stepping up and
simply telling your key account that, no, we're not able to implement
this in a few days without compromising quality. And if the competitor
say's he can, then he's lying.
It really depends. If the request is to add, say, a search for accounts by user's social security number, it might be reasonable and easy. If instead, the request is for an entire search infrastructure which doesn't currently exist at all, then it might be unreasonable.
Agile methods aren't magic. Changing things on release day still doesn't work. Agile methods aim to minimize the negative impact of change. They can't always eliminate it, though. They recognize that change is inevitable, so you might as well expect it. They also recognize that change can improve the product. If the client needs something he didn't originally expect, why not give it to him? (Possibly at the expense of other features he decided he can do without.) It results in a better product, a happier customer, and possibly a repeat customer.
- how much work is already done (%)
-
RE: Another question for the database gurus out there
Why do you need this functionality at all? I pray that this isn't supposed to be some kind of security, because if so, you need to revisit your entire plan.
I can't envision a system in which random numbers in the url are fundamentally better than sequential numbers in the URL. -
RE: I don't wanna create a WTF.. database question
@t-bone said:
true but in this case it's a case of inserting for example order lines and making sure it's always the same sequence on packing slips and invoices etc, there are not a huge number of records (with the same foreign key to a header table), and there are not a huge number of rearranges. It's to retain sequence after entry
The index method is still safer than the float method. It's rarely safe to assume that number of changes will be small. If the number of items (order lines in your example) isn't expected to change much, then there's no real reason to make it dynamic at all. Put it in a config file. Don't mess with the complexities of a database unless you need them, and if you do need the complexities of a database, then use it correctly (safely). If you build in the capability to easily rearrange items, expect that people will use, and even abuse, that capability. Just because it seems unreasonable to make a lot of changes doesn't mean it won't happen.
I believe that the insert-in-the-middle method with floats could actually run out of precision pretty quickly, too.
-
RE: Rational agrument against Hungarian notation?
@dhromed said:
Of course I know my own code.
You don't make your code understandable for yourself, but for other people and your future self.
It's about the other guy who goes directly to line 258 to fix a bug that occurred at line 258, sees "coordSet" and would like to know what the hell it is.
Though in many cases he can get it from the context.
Sorry, I used you to mean both "you" and "one". The part directed actually at you was a little sarcastic. I expect that you know your own code. As for someone else editting your code, I still stand by the assertion that if one doesn't understand the code, then one isn't safe changing the code. I wouldn't want anyone messing with my code who was so lost that he couldn't (easily) figure out the type of a variable.
Seriously, editting code that one doesn't understand is dangerous. e.g. Let's say the error at line 258 is a null pointer exception. So, the obvious solution is to simply wrap the code in an "if (arrCoordSet != null)" block. Howver, that only works if the coordSet is expected to be null sometimes. If instead coordSet should never be null, then it's a dangerous hack, because now it's just masking the bug, which will likely come back later in a harder-to-diagnose form. That's probably an overly-simplified example, but I think the point is correct. One can't safely edit code that one doesn't know.
-
RE: I don't wanna create a WTF.. database question
@Angstrom said:
I'd like to introduce you to my friend, SQL F701 ON UPDATE
CASCADE. At that point it becomes more of a practicality versus
purity discussion: on update cascade keys are marginally less portable
and, unless used CAREFULLY and documented well, can lead to updates
taking an unexpectedly long time and to hard-to-comprehend database
schemas.
Don't go confusing things with your facts and logic.
-
RE: I don't wanna create a WTF.. database question
I've found a number of times that it bites me when I don't create an id key. The fundamental problem with using unique data in the table as the primary key is that any useful or "real" data in the table is subject to change, including the primary key. Change the primary key, and now any other tables which reference that key also need to be updated.
e.g. Let's create a table of users. The obvious primary key is the username. So other tables reference that key to show ownership/authorship/whatever. But Suzie Random (srandom) gets married, becoming Suzie Random Hacker, and wants to change her username (to srhacker). It's possible, but it's a hassle, because tons of things point to her username as a foreign key. If they pointed, instead, to an id which has no meaning outside the database, then nothing would need to change except the one entry in the user table.
I think using meaningful data as a primary key can typically be viewed as data replication. I almost always create id keys. It just normally makes things simpler. Worrying about the efficiency of joins/etc during design falls under premature optimization, generally (but possibly not always). Of course, I always make the "logical" primary key (username in this case) unique. -
RE: I don't wanna create a WTF.. database question
@Goplat said:
In schema 2 you could avoid the problem of having no numbers between n
and n+1 by using strings instead. You can always find a string that
sorts between two other strings, e.g. if you want an index between A
and B, use AM (M is the middle letter of the alphabet).
Um. Insert between A and AA?