| # |
Dec 28th 2018, 13:10 |
G00DSP33D |
True, but again, the setup would take us more work. Right now a new field is basically 1 line of code in a config file. If we switch our TEXT field to a JSON field, we could something like this: http://mysqlserverteam.com/mysql-5-7-lab-release-json-functions-part-2-querying-json-data/ |
| # |
Dec 28th 2018, 13:10 |
 admad |
"If "price" is serialized into a JSON string" putting price field in json too isn't the best idea |
| # |
Dec 28th 2018, 13:10 |
challgren |
How your going about it is overkill like @admad said |
| # |
Dec 28th 2018, 13:09 |
challgren |
In terms of performance use non-dynamic fields the times they are not needed take up very little space yet provide better speed |
| # |
Dec 28th 2018, 13:08 |
challgren |
Then use non-dynamic fields, your really hindering yourself in scalability by using dynamic data and regexes to sort the data |
| # |
Dec 28th 2018, 13:07 |
G00DSP33D |
That's something we really miss right now in our system. |
| # |
Dec 28th 2018, 13:07 |
G00DSP33D |
in terms of performance we're really happy with this light approach we have now, but we just want to switch to 3.x for all the other cool stuff. And check how we can query against those dynamic fields. |
| # |
Dec 28th 2018, 13:06 |
admad |
you'll have to explicitly set the type to json in table schema |
| # |
Dec 28th 2018, 13:06 |
G00DSP33D |
yes indeed, that's why we try to avoid a full EAV setup |
| # |
Dec 28th 2018, 13:05 |
admad |
using json field for variable content fields/blobs is fine, EAV can be overkill |
| # |
Dec 28th 2018, 13:05 |
G00DSP33D |
also true |
| # |
Dec 28th 2018, 13:04 |
challgren |
Nah you dont need all the extra controllers and views |
| # |
Dec 28th 2018, 13:04 |
G00DSP33D |
We did that in the past, but required to set up extra controllers, models, views, etc., next to all the extra SQL work. Right now in order to add a new field, we just add a new element to an array and it's done. |
| # |
Dec 28th 2018, 13:03 |
challgren |
base_table -> attribute_table |
| # |
Dec 28th 2018, 13:03 |
challgren |
Or have associated tables |
| # |
Dec 28th 2018, 13:03 |
G00DSP33D |
That's why we try to keep it dynamic. |
| # |
Dec 28th 2018, 13:03 |
G00DSP33D |
The problem is that we don't want to go crazy wide with columns in our Pages table |
| # |
Dec 28th 2018, 13:03 |
challgren |
Have you looked into https://book.cakephp.org/3.0/en/orm/query-builder.html |
| # |
Dec 28th 2018, 13:02 |
admad |
replacement for notEmpty are specific `allowEmpty*` functions https://github.com/cakephp/bake/pull/486 |
| # |
Dec 28th 2018, 13:02 |
challgren |
You'll need the typemap |
| # |
Dec 28th 2018, 13:02 |
G00DSP33D |
We also know that MySQL now supports true JSON fields, so we're also looking into getting those to work with CakePHP. |
| # |
Dec 28th 2018, 13:02 |
challgren |
I personally would suggest just storing those dynamic fields non-dynamic and then changing the validation set based on the product type |
| # |
Dec 28th 2018, 13:02 |
admad |
There is no replacement $hasRendered. In 4.x you can simply call render() multiple times |
| # |
Dec 28th 2018, 13:01 |
G00DSP33D |
Yes, fully agree, awesome features in there! |
| # |
Dec 28th 2018, 13:00 |
G00DSP33D |
But thanks for the suggestion you gave, that could already help us with the validation part. |
| # |
Dec 28th 2018, 13:00 |
challgren |
It takes a bit but once you understand it, its a much better platform than 2.x |
| # |
Dec 28th 2018, 13:00 |
G00DSP33D |
We're also still wrapping our heads around this migration |
| # |
Dec 28th 2018, 13:00 |
challgren |
Im kind of in the same boat converting from 2.10 to 3.6-7 |
| # |
Dec 28th 2018, 13:00 |
G00DSP33D |
Haha, understand you completely challgren |
| # |
Dec 28th 2018, 12:59 |
challgren |
Granted I'm a 3.x newbie (Kind of in the same boat you are) but not that Im aware of but someone else may have more knowledge on that |
| # |
Dec 28th 2018, 12:59 |
G00DSP33D |
Now in 2.x we have to use REGEX to get that done, which is off course horrendous work and extremely slow. |
| # |
Dec 28th 2018, 12:58 |
G00DSP33D |
Our second question is whether CakePHP 3.x now offers any way to query against serialized data using complex data types. If "price" is serialized into a JSON string, can we now for example sort our product pages by price? Or query to select pages with a certain minimum price? |
| # |
Dec 28th 2018, 12:57 |
G00DSP33D |
Aha thanks <slackebot>, that looks interesting. |
| # |
Dec 28th 2018, 12:56 |
G00DSP33D |
So we were happy to learn that support for comp[lex data types has been added in 3.x. But we're wondering whether there are now more intelligent way stop do what we are doing in terms of validation. |
| # |
Dec 28th 2018, 12:56 |
challgren |
https://book.cakephp.org/3.0/en/orm/validation.html#using-a-different-validation-set |
| # |
Dec 28th 2018, 12:56 |
challgren |
You can use different validation sets |
| # |
Dec 28th 2018, 12:55 |
G00DSP33D |
So we dynamically add those validation rules in the beforeValidate. This allowed us to validate field values that are serialized into JSON later on. |
| # |
Dec 28th 2018, 12:54 |
G00DSP33D |
Our approach: in beforeValidate we check the contents of the field Page.type. Let's say that it contains "product_page". In a CakePHP Config we kept a list of "dynamic fields" per page type, and their respective validation rules. |
| # |
Dec 28th 2018, 12:53 |
challgren |
If you want tha ability to sort or filter |
| # |
Dec 28th 2018, 12:52 |
challgren |
You may need to define those fields even if they are unnecessary for every record |
| # |
Dec 28th 2018, 12:51 |
challgren |
I run an app that integrates with QBO but I dont store dynamic data in JSON |