| # |
Dec 28th 2018, 13:24 |
G00DSP33D |
Thanks again a million for all the help and ideas both to challgren and admad. If you're interested, I'll report back with the final setup we'll go for. If we can share any code, also will do so. |
| # |
Dec 28th 2018, 13:24 |
 challgren |
My guess is 4.x will break it? |
| # |
Dec 28th 2018, 13:23 |
admad |
should only need updating deprecated methods and such if you do want to use it |
| # |
Dec 28th 2018, 13:23 |
challgren |
Ahh ok I was going to go down the STI road and was going to UseMuffin |
| # |
Dec 28th 2018, 13:22 |
admad |
@challgren highly doubt anyone is using the muffin one, it has been updated in ages :slightly_smiling_face: |
| # |
Dec 28th 2018, 13:22 |
G00DSP33D |
Yep, same here, always tried to avoid that and use the pure ORM features in Cake. But these could be the ideal compromise for us. |
| # |
Dec 28th 2018, 13:21 |
challgren |
You would have to define custom SQL function which I honestly havent gotten into yet |
| # |
Dec 28th 2018, 13:21 |
G00DSP33D |
But since we don't want to overlook anything, we're definitely going to look in all the suggestions you've made. |
| # |
Dec 28th 2018, 13:21 |
G00DSP33D |
I will be honest. The way we set up fields and validate data is perfect for us, it's really fast. Just the querying is a nightmare. So if we can use the SQL functions as you suggested earlier with true JSON fields, we would be all set. |
| # |
Dec 28th 2018, 13:21 |
challgren |
@admad UseMuffin not good to use anymore? |
| # |
Dec 28th 2018, 13:20 |
admad |
https://github.com/robotusers/cakephp-table-inheritance |
| # |
Dec 28th 2018, 13:20 |
G00DSP33D |
But we'll look into it, thanks for the suggestion. |
| # |
Dec 28th 2018, 13:20 |
challgren |
https://github.com/UseMuffin/Sti |
| # |
Dec 28th 2018, 13:20 |
G00DSP33D |
Nope I must admit |
| # |
Dec 28th 2018, 13:19 |
challgren |
Have you explored STI? |
| # |
Dec 28th 2018, 13:18 |
G00DSP33D |
That can vary. The smalles project we have, has about 3. The largest one has around 16 if I remember correctly. |
| # |
Dec 28th 2018, 13:18 |
challgren |
how many different page types? |
| # |
Dec 28th 2018, 13:17 |
G00DSP33D |
Less than 20 :D |
| # |
Dec 28th 2018, 13:17 |
challgren |
How many tables do you have in your database? |
| # |
Dec 28th 2018, 13:16 |
G00DSP33D |
Check the 'dyn_fields' key. We simply retrieve that array in the beforeValidate, and all those rules to the validator of the Page model. After validation we remove them, and in the beforeSave callback we serialize the data into JSON. |
| # |
Dec 28th 2018, 13:14 |
G00DSP33D |
Just to give you a better idea, here's our Pages CakePHP configure for a homepage in our system. https://pastebin.com/0vLqqTqx |
| # |
Dec 28th 2018, 13:14 |
G00DSP33D |
nice |
| # |
Dec 28th 2018, 13:13 |
challgren |
https://book.cakephp.org/3.0/en/orm/query-builder.html#using-sql-functions |
| # |
Dec 28th 2018, 13:12 |
G00DSP33D |
A scaled down EAV without all the overhead, and a fast and easy query against JSON data. So we're going to check how we can support those MySQL JSON fields in CakePHP. |
| # |
Dec 28th 2018, 13:10 |
G00DSP33D |
This would give us the best of both worlds. |
| # |
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. |