I'm using the Zend_Validate_Int class to validate integers in a form. When the number is something like 1,000 it passes validation, but then removes the comma. Does anyone know a way I can get it to keep the comma?
Zend_Validate_Int is not your problem.
This validator accepts a value to validate and simply returns a boolean and only a boolean. It will validate as true an integer with a comma. The comma is str_replaced to empty but that value is never returned.
Your problem may be involved with any locale you have set or with any type casting you are using.
You can dump the variable values at every step to find where the actual change takes place.
Your best bet to fix this would likely be a view helper to format the values for output.
The purpose of Zend_Validate_Int is to make sure that final number you get is an integer not a float, you probably need to use another validator or a regular expression, or simply try Zend_Validate_Float.
Related
I have a weird issue in my PHP which gives an empty value at 1 of my input fields.
You can see that the value has an empty string
You definitely can tell It shows an error when there is nothing in that input. There is no space character given
Here you see what it sends if I insert a user
This is the error that have to appear
I don't know what to do.
You could use trim() on that value before validating it - it will remove any spaces at the beginning and end of the string, so if the string only consists of one space (or several spaces) originally, it will be empty after applying trim() to it and therefore not validate.
Is there any case for using an empty string instead of null? I'm looking for any domain or business context where you would want to use the empty string instead of using null
I'm pondering this in terms of the HTTP stack, for example in php a request with a query string that looks like https://example.com/something?key= would be interpreted as an empty string.
var_dump($_GET['key']);
string(0) ""
And for every use case my limited imagination can conceive, this should always be converted to null so why would anyone have a need to store "" in a database field or something like that?
The concept of NULL is used to represent a value that is not known. This is easier to grasp in the database context, where an entire row is inserted in the database at a time. The fields whose values are not known are initialized with NULL.
The programming languages that support the concept usually use NULL as the value of the uninitialized variables. This usage shifts the general perception of NULL towards the idea of "not set". In fact, the semantics of NULL in this context is also "unknown".
An empty string ('') is a different thing. It represents the absence of any character in a string. It doesn't mean the value (of type string) is not known; it is known: it is empty. Using it instead of NULL is a logic error.
In the context of the HTTP GET request whose URL is https://example.com/something?key=, processed by a PHP script, $_GET['key'] is '' (the empty string). The value is known, the key variable is present in the URL and its value is the empty string. But $_GET['foo'] is correctly evaluated by PHP as NULL. The value is simply not known. It is not the empty string; it can be any value but since it was not sent in the URL we cannot know it.
As the database is concerned, an empty string and a NULL values are two different things. You can tell them apart and query each other specifically. As a weakly typed language, PHP tends to blur the line, but that doesn't mean it is the case everywhere in the software ecosystem.
On the other hand, one of the primary uses of php is to handle http form values, which are all of type string by nature. Maybe that doesn't help either.
In the past, I have always used preg_match() to do this.
Just came across ctype_alpha() at http://www.php.net/manual/en/function.ctype-alpha.php.
Is this a quicker and/or less resource intensive way to confirm that a string just contains letters?
Note that I will be using this string later in a SQL query, and will be putting quotes around it but not doing anything more for SQL injection. I know this is not typical, however, I am generating dynamic SQL, and wish to do it this way.
ctype-alpha can have two positive and not only one. Check the notes on php manual about 'Tyrunur', and then think if the string is empty is true (second state).
So before go in your sql, you have:
first to set and control each 'locale' for every net-user,
then if empty or not and
if is valid string or not.
After these you can use ctype-alpha.
Are you sure is so fast? i don't believe so.
Just wondering, if is there any class, function or ideia on how to validate a specific value/variable against a mysql data type.
We've got in PHP the is_int() is_string() is_float() etc etc... But we do not have them all. Or do we? Any Cheat sheet? Any thoughts?
EDIT:
The point basically is:
Go trought a array of values (comming from a CSV for instance).
I know what table, and have all the column information (data type s well) (with adodb).
Just check if each value fits in a specific column...
If the data is coming from a CSV file, you have to remember that all the values are going to be strings (even numeric strings still have a string type).
So you can't use is_int()/is_float()/etc., because that only tells you about the type or the variable. You could use is_numeric() to check the value, but this will allow for things like exponential notation like "+0123.45e6". Sometimes ctype_digit() can be useful for testing integers for this reason, since it will only allow the numbers 0-9 to be present in a string for it to return true.
Regular expressions can also be used to identify pattern-based data types, but you do have to watch for performance overhead when dealing with large data sets. It's almost always advisable from a performance perspective to use the preg_ family of functions instead of the ereg functions.
If you're validating things like ENUM or SET types, you'll probably need to make an array containing legal values (or extract these with a query) and then check the value against them with in_array().
For CHAR/VARCHAR fields, you could parse the column definition and then check whether the length of the value falls within the constraints.
If the NULL type is allowed on any of your columns, you'd also need to check against this (and probably map empty values or the string "NULL" to an actual NULL value).
If you're looking to actually escape these values properly, look into using prepared statements and the PDO (PHP Data Objects) extension. This allows MySQL to properly escape the data based on type. (You can also use prepared statements with MySQLi.)
If you're looking for specific data types and how to identify them, then you might want to edit your question to facilitate more complete answers.
I need your help please.
We have a PHP application running on MySQL, and we need to use PostgreSQL for a new customer.
the problem is that when we insert empty strings in a field of type numeric, we get an error.
I think we should actually use NULL instead of empty string.
However we would like to avoid having to recode all the SQL code of our application, my question is whether it is possible in the structure of a table (or elsewhere) to ensure that our numeric column accepts empty values? or convert them to NULL?
In the documentation I have seen that it is possible to define your own types, it is possible for example to create a type based on numeric and ensure that it accepts empty values?
If yes how? I found no solution
Thank you
the problem is that when we insert
empty strings in a field of type
numeric, we get an error.
That's correct, a string isn't a number. Not even an empty string.
I think we should actually use NULL
instead of empty string.
That's correct, your current SQL is wrong. If your MySQL-configuration would use a better SQL_MODE, your queries will also fail on MySQL. Fix your code, it's by far the best option you have.
Hacking around by creating dummy datatypes is just a hack, it's not a solution for bad SQL. The problem is your SQL, not your database.