When creating tables for a CakePHP 2.X application there are certain column names that Cake will automatically process in special ways. The most obvious I can think of would be "created" and "modified" (which Cake will automatically handle when rows are created or edited). There's "name" which will by default be used as a model's display name. To a lesser degree "email" and "phone" automatically select their appropriate validation rules when Baking the project.
My Question is:
Does anyone have a comprehensive list of these column names?
I've tried looking through the CakePHP site and Google searches, but either this list does not exist, or I'm using the wrong the terms.
Thank you.
For the forms, if the field name is:
'pasword', 'passwd', 'password' => it will be displayed as password fields
'tel', 'telephone', 'phone' => it will be displayed a type = "tel"
'text' => textarea
'time' => time drop-downs
'datetime', 'timestamp' => date + time drop-downs
'date' => date drop-downs
'created', 'updated', 'modified' are automatically filled when using model->save()
You also mentioned "name" which is a model attribute. The list of attributes is here
You can see more about how the fields are displayed in forms in the FormHelper.php and more about how the model works in Model.php from Cake core
Regarding cake bake validations:
if field name is email, it will be validated as email.
The other validations are based on field type:
type string => validation: notEmpty
type integer => validation: numeric
type float => validation: numeric
type boolean => validation: boolean
type date => validation: date
type time => validation: time
type datetime => validation: datetime
type inet => validation: ip
Related
I need help to search in the different indexes of the same cluster with different fields. For example: If I have a cluster name demo in which I have 2 indexes menu_items and purchase_orders. Both indexes contain different columns to search. Index menu_items contains 'label' field and index purchase_orders contains 'id' and 'supplier_reference' field.
$params = [
'index' => 'menu_items,purchase_orders',
'_source' => 'label,id,supplier_reference',
'body' => [
'query' => [
'bool' => [
'must' => [
'multi_match' => [
'query' => $keyword,
'type' => 'bool_prefix',
'fields' => ['label', 'id', 'supplier_reference'],
],
],
],
],
],
];
Now If I am searching for any term '3312' which is available in both indexes so this query working good and another term 'supplier' is not available in another index at that time I got an error.
Can anyone help here? How can I achieve this? How can we find fields in two or more different indexes?
I face an issue as described below and as a solution what I found here is, we need to do the proper mapping.
Related to mapping, Elasticsearch has the built in ability to detect the type of the fields of a document and generate a schema and apply it throughout the index. But this causes an error while two indexes have different data types for the same field. ex: if index1 has id field with long data type and index2 has id field with the string data type. At that time search operation gives an error for search related to the id field which I described in the question.
can someone explain this laravel validation
'email' => 'unique:users,email_address,NULL,id,account_id,1'
What's the purpose of NULL, id in it?
Basic Usage Of Unique Rule
'email' => 'unique:users'
Specifying A Custom Column Name
'email' => 'unique:users,email_address'
Forcing A Unique Rule To Ignore A Given ID
'email' => 'unique:users,email_address,10'
Adding Additional Where Clauses
You may also specify more conditions that will be added as "where" clauses to the query:
'email' => 'unique:users,email_address,NULL,id,account_id,1'
In the rule above, only rows with an account_id of 1 would be included in the unique check.
Documents References (i.e. https://laravel.com/docs/5.0/validation)
I'm having trouble validating an array of fields that requires a custom rule. I have the following validator:
$validator = Validator::make($request->all(), [
'order' => 'required',
'service_id.*' => Rule::unique('order_services')->where('order_id', $request->order),
'due_date.*' => 'required|date',
'vendor' => 'required|integer',
'instructions' => 'string|nullable',
'lock_box' => 'string|nullable',
]);
The due date array validates just fine, but the service id returns the following error:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'service_id.0' in 'where clause' (SQL: select count(*) as aggregate from `order_services` where `service_id`.`0` = 10 and `order_id` = 100f)
The service id rule prevents duplicate records with the same order number and service id
The rule works as expected when validating a single service ID, I'm just not sure how to validate multiple service IDs at the same time.
Thanks in advance
By default Laravel uses key for unique role and because it's an array, keys are 0, 1, 2 and so on. The solution is adding column name for unique rule like this:
Rule::unique('order_services', 'id')->where('order_id', $request->order),
Obviously in your case you might need other column name than id (it depends on your application)
I'm using Cakephp 3.2.7 as a framework and create a query with select alias.
$posts = $this->Posts->find()
->select(['id' => 'Posts.id','userid'=>"Posts.user_id"])->toArray();
I want to get id as string not integer (the column type in mysql is integer) and get the userid as integer (the column type in mysql is also integer) but use alias convert it to string.
Is there any way to fetch all of Id columns in all of model as string or at least can define data type in query?
Actually I agree with #drmonkeyninja and I don't know why you want to do this.
Also I don't guarantee that what I'm about to write is safe and is a clean way to achieve what you are trying to do.
Anyway you can modify the table schema and change the column type. See the manual
$this->Posts->schema()->addColumn('userid', [
'type' => 'integer',
])
->addColumn('id', [
'type' => 'string',
]);
Finally I found the solution. I add a mutator to entity of post class.
protected function _getId()
{
return (string)$this->_properties['id'];
}
that force id to return as string.
I'm using cakephp validation for a field called birthdate.
my model is
'birthdate' => array(
'rule' => 'date',
'message' => 'Enter a valid date',
'allowEmpty' => true
),
my question is how come it's still save correctly even though it's invalid input. e.g:
March 27, 1988
so, if I put it like this, and the array result like this
//this will work
'birthdate' => array(
'month' => '3#',
'day' => '27',
'year' => '1988'
)
//this will NOT work
'birthdate' => array(
'month' => '#3',
'day' => '27',
'year' => '1988'
)
why the first one still validate it (still save correctly. e.g: the end result still march 27, 1988)? but I would like to have consistency. is there anyway to report an error?
Complex data type deconstruction
Dates are being passed as arrays, so they need to be formatted to a string first. In case the column in the database is of type date*, the value is being formatted automatically so that it fits the proper column type format.
Ultimately this is done in Model::deconstruct() (it ends up there when calling Model::set(), which normally happens before validation), where the individual values are being passed through sprintf():
$date[$index] = sprintf('%02d', $date[$index]);
https://github.com/cakephp/cakephp/blob/2.4.5/lib/Cake/Model/Model.php#L1336
Integer casting
And that's the answer to your first question, it's that formatting directive that is responsible for this behavior, it casts the individual date values to integers, where 3# evaluates to a number, while #3 fails (and ends up as 00), that's how string conversion in PHP works.
See http://php.net/manual/language.types.string.php#language.types.string.conversion
Use custom validation/formatting
So in order to be able to trigger an error on such input you'll either have to use a custom validation rule, which would require to for example pass the data using a different fieldname so that it's not being formatted in Model::set(), or use custom formatting (for example by overwriting Model::set() or Model::deconstruct()) to flatten the complex value in a way that the individual values are not being casted.