# |
Jun 14th 2019, 08:23 |
kgb.acct.personal |
Because on `env.default` states: ``` # Having this file in production is considered a **SECURITY RISK** and also decreases # the boostrap performance of your application. ``` |
# |
Jun 14th 2019, 08:23 |
kgb.acct.personal |
Is it safe to use `.env` on prod? |
# |
Jun 14th 2019, 08:23 |
neon1024 |
Morning everyone! :wave: Happy Friday :tada: |
# |
Jun 14th 2019, 08:21 |
val |
Something like a bean in Java. |
# |
Jun 14th 2019, 08:16 |
dereuromark |
see docs, they do if you have name or title field |
# |
Jun 14th 2019, 08:12 |
noel |
Do tables have a default displayField or is this `id`? |
# |
Jun 14th 2019, 08:00 |
noel |
This seems to work but not sure if it's DRY: ``` $exists = false; $connection = ConnectionManager::get('default'); $tables = $connection->execute('show tables;')->fetchAll('assoc'); foreach (array_values($tables[0]) as $key => $tableName) { if ($alias === $tableName) { $exists = true; } } return $exists; ``` |
# |
Jun 14th 2019, 07:54 |
noel |
What's the best way to check if a db table exists? |
# |
Jun 14th 2019, 07:40 |
val |
Another way to optimize Entity would be to refactor $_properties array to a new class containing only those properties. |
# |
Jun 14th 2019, 07:35 |
spriz |
Not sure how I feel about that, but it works! :) |
# |
Jun 14th 2019, 07:35 |
spriz |
->contain([ 'EanProductRelationTargets' => function (Query $q) { return $q->where(['EanProductRelations.type' => EanProductRelation::TYPE_ALTERNATIVE_PROCUREMENT]); }, ]); |
# |
Jun 14th 2019, 07:35 |
spriz |
``` |
# |
Jun 14th 2019, 07:35 |
spriz |
OK, I can actually just reference that join table in the where :thinking_face: |
# |
Jun 14th 2019, 07:28 |
val |
I tested the memory by using `new MyEntity(...)` and generating the entities with some random values without any query to the database. So the memory overhead due to results buffering was not present. |
# |
Jun 14th 2019, 07:28 |
spriz |
but how do I reference the join table and not either `articles` or `tags` table? |
# |
Jun 14th 2019, 07:24 |
admad |
if that's not enough you could try using your own entity class implementation |
# |
Jun 14th 2019, 07:24 |
challgren |
https://book.cakephp.org/3.0/en/orm/retrieving-data-and-resultsets.html#using-innerjoinwith |
# |
Jun 14th 2019, 07:24 |
admad |
depending on how you want to consume the results, i believe disabling results buffering might be the main thing that would help reduce memory consumption |
# |
Jun 14th 2019, 07:24 |
spriz |
Data saved like this https://book.cakephp.org/3.0/en/orm/saving-data.html#saving-additional-data-to-the-join-table :slightly_smiling_face: |
# |
Jun 14th 2019, 07:23 |
val |
Okay. I believe there is a way to optimize Entity class a bit - $_properties is an array. It would use less memory if each property would be an actual class property instead of an array item in $_properties. |
# |
Jun 14th 2019, 07:23 |
spriz |
now I only want all `tags` for an `article` that has priority `3` |
# |
Jun 14th 2019, 07:23 |
spriz |
@challgren cheers mate, but I need to do it on the join table :S Consider `articles`, and `tags` and then `articles_tags` that has a column like `priority` |
# |
Jun 14th 2019, 07:22 |
admad |
you can set your own entity class for the table to be used for hydration, but i think you will still have to use a class which implements EntityIterface |
# |
Jun 14th 2019, 07:21 |
challgren |
@spriz https://book.cakephp.org/3.0/en/orm/retrieving-data-and-resultsets.html#filtering-by-associated-data-via-matching-and-joins |
# |
Jun 14th 2019, 07:19 |
admad |
so turn off hydration, disabled buffering and then use formatResults() to create objects of type you want |
# |
Jun 14th 2019, 07:18 |
admad |
yes |
# |
Jun 14th 2019, 07:18 |
val |
Perhaps $query->formatResults(...)? |
# |
Jun 14th 2019, 07:15 |
val |
Using arrays is also not optimal. We try to optimize that. Is there an easy way to convert the cake's result set to our custom objects without too much custom coding? |
# |
Jun 14th 2019, 07:13 |
admad |
if the memory consumed if still not within what you can spare than skip the ORM and directly use db level operations |
# |
Jun 14th 2019, 07:12 |
admad |
1st thing you can try in turning off hydration |
# |
Jun 14th 2019, 07:12 |
admad |
so my statement "Objects take more memory than arrays" might not be factual but entities (within a resultset object) in cake 3 will take significantly more memory than corresponding arrays of cake 2 |
# |
Jun 14th 2019, 07:11 |
val |
That is correct. |
# |
Jun 14th 2019, 07:09 |
admad |
an entity is more complex than a plain php object with properties |
# |
Jun 14th 2019, 07:07 |
val |
This is a common misconception. Objects do not take more memory than arrays. Please take a look at https://gist.github.com/nikic/5015323. I personally tested it. A plain PHP object with 6 predefined fields occupies 50% less memory then an associative array with 6 fields. I may agree with you that it is not optimal to retrieve 153000 entities at a time but sometimes business rules require that and there is no better alternative. |
# |
Jun 14th 2019, 06:57 |
spriz |
Any good tricks to contain a `BelongsToMany` with a WHERE clause on some data in the join table? Usually I make it a `HasMany` and add the filter and chain the `HasMany.BelongsTo` - but it is a bit awkward |
# |
Jun 13th 2019, 21:49 |
unclezoot |
looks like my hasOne association was wrong, obviously thought bake could read my mind, but instead put in hasMany (sigh) |
# |
Jun 13th 2019, 21:25 |
noel |
I'm working within a helper, so I guess ideally via static methods. |
# |
Jun 13th 2019, 21:25 |
noel |
Is there anyway I can query the db schema programmatically? |
# |
Jun 13th 2019, 21:23 |
noel |
It's a bit weird because it's returning true for an alias to a table name that is being setup in an association. So what I'm really looking for is a way of checking whether a given string corresponds to an actual table, as distinct from a string which corresponds to an alias of a table setup by an association. `TableRegistry::getTableLocator()->exists` seems to return true for both of those cases. |
# |
Jun 13th 2019, 21:21 |
ricksaccous |
so maybe that won't work |
# |
Jun 13th 2019, 21:21 |
ricksaccous |
but have 0 records |