>I'm willing to bet that if you find yourself wanting to use regular expressions in a Cocoa program, one of two things is happening. Either you're coming from a scripting background and you haven't really figured out how to program in Cocoa yet, or you're using Cocoa for a job that could be better done with a script.
I'm willing to bet that none of your apps dealt heavily with string parsing and/or validation. You can certainly avoid using regular expressions if you have to, but I suspect that anyone who's done any significant text analysis or parsing using regexp will sing the praises of PCRE to their deathbed. Regular expressions are an incredibly useful, robust tool that can and will save you hours and hours of tedious string parsing. Just because you haven't come across any reason to use them doesn't mean that they're not crucial to other applications, or that using them is some kind of cop out that die-hard coders would never consider. Also, I've never worked with Cocoa, but I'd be surprised if there really wasn't any way to get regexp support, even through a 3rd party library.
I certainly don't disagree with you that the query *should* fail if you try to insert, let's say, 5000 into a tinyint field (which will get truncated to 127 in mySQL), but I also don't think it's a single point of failure for mySQL as an enterprise class solution, as some people seem to be making it out to be. It's an implementation decision that the mySQL developers made, and the application programmer just needs to be aware of it. I'm sure you know as well as I do that any tool, whether it be mySQL, postGres, or anything else, will have certain design aspects that make you ask, "why would they do it this way?". Though now that you've got me thinking about it more, this integer truncation thing IS actually starting to bother me. Maybe we can at least get some sort of config flag to turn off that behavior:)
>Validation only gets you so far especially if you have one database and many clients. The last thing you want is for one client to think a field is bigger than it is and start messing with your accounting numbers.
I don't really understand how "validation only gets you so far", though. The database field definitions act as kind of a contingency validation, but your program should sanity check everything:
if ( $given_num > $max_num ) {
no_query(); }
I think the problem really comes into play when you have multiple developers working on one database. Still, they should understand the database structure if they're working the app.
>one is the few propietry features of mysql and the other is that if you wan't to support both you have to wrap stuff yourself as php has totally seperate calls for postgresql and mysql
You should be wrapping your database calls anyway, in preparation for what the future holds. Personally, I've gone so far as to create an abstraction layer in PHP with methods such as select(), order_by(), limit(), etc, that get called like:
so that I can switch my RDBMS by alterting just the abstraction layer for that RDBMS, not by having to edit my entire codebase. Yes, compatibility problems still arise, but generally, by having such specific functions for query data, I can do clever query generation to handle the incompatibilities between mySQL, PostGres, msSQL, etc... Yes, it's less efficient than hardcoding queries, so it's a matter of how important portability is to you. Remember though, it's usually easier to upgrade your hardware than to rewrite an entire app.
>I would call that commercial and because MySQL will *truncate* numbers to fit fields if they are too big, I would say PostgreSQL is needed for that.
This is a legitimate point, but the values should've been sanity checked prior to ever being passed to the query. I realize it's better to have a failsafe (the query failing) in the event that they do make it, but having the database layer throw a general error back to the client (which hopefully is at least hidden and translated into some sort of "unknown error occurred" message) is not the way to handle improper user data.
Slashdot Mirror
>I'm willing to bet that if you find yourself wanting to use regular expressions in a Cocoa program, one of two things is happening. Either you're coming from a scripting background and you haven't really figured out how to program in Cocoa yet, or you're using Cocoa for a job that could be better done with a script.
I'm willing to bet that none of your apps dealt heavily with string parsing and/or validation. You can certainly avoid using regular expressions if you have to, but I suspect that anyone who's done any significant text analysis or parsing using regexp will sing the praises of PCRE to their deathbed. Regular expressions are an incredibly useful, robust tool that can and will save you hours and hours of tedious string parsing. Just because you haven't come across any reason to use them doesn't mean that they're not crucial to other applications, or that using them is some kind of cop out that die-hard coders would never consider. Also, I've never worked with Cocoa, but I'd be surprised if there really wasn't any way to get regexp support, even through a 3rd party library.
I certainly don't disagree with you that the query *should* fail if you try to insert, let's say, 5000 into a tinyint field (which will get truncated to 127 in mySQL), but I also don't think it's a single point of failure for mySQL as an enterprise class solution, as some people seem to be making it out to be. It's an implementation decision that the mySQL developers made, and the application programmer just needs to be aware of it. I'm sure you know as well as I do that any tool, whether it be mySQL, postGres, or anything else, will have certain design aspects that make you ask, "why would they do it this way?". Though now that you've got me thinking about it more, this integer truncation thing IS actually starting to bother me. Maybe we can at least get some sort of config flag to turn off that behavior :)
>Validation only gets you so far especially if you have one database and many clients. The last thing you want is for one client to think a field is bigger than it is and start messing with your accounting numbers.
I don't really understand how "validation only gets you so far", though. The database field definitions act as kind of a contingency validation, but your program should sanity check everything:
if ( $given_num > $max_num ) {
no_query();
}
I think the problem really comes into play when you have multiple developers working on one database. Still, they should understand the database structure if they're working the app.
>one is the few propietry features of mysql and the other is that if you wan't to support both you have to wrap stuff yourself as php has totally seperate calls for postgresql and mysql
You should be wrapping your database calls anyway, in preparation for what the future holds. Personally, I've gone so far as to create an abstraction layer in PHP with methods such as select(), order_by(), limit(), etc, that get called like:
$query->select('something');
$query->from('widgets');
$query->where( 'widgetID=10');
so that I can switch my RDBMS by alterting just the abstraction layer for that RDBMS, not by having to edit my entire codebase. Yes, compatibility problems still arise, but generally, by having such specific functions for query data, I can do clever query generation to handle the incompatibilities between mySQL, PostGres, msSQL, etc...
Yes, it's less efficient than hardcoding queries, so it's a matter of how important portability is to you. Remember though, it's usually easier to upgrade your hardware than to rewrite an entire app.
>I would call that commercial and because MySQL will *truncate* numbers to fit fields if they are too big, I would say PostgreSQL is needed for that.
This is a legitimate point, but the values should've been sanity checked prior to ever being passed to the query. I realize it's better to have a failsafe (the query failing) in the event that they do make it, but having the database layer throw a general error back to the client (which hopefully is at least hidden and translated into some sort of "unknown error occurred" message) is not the way to handle improper user data.