Log message #3941118

# At Username Text
# Sep 30th 2016, 18:00 inoas see you around guys
# Sep 30th 2016, 17:58 dereuromark how do I increase the defaults for https://easyengine.io/tutorials/php/increase-file-upload-size-limit/ on cakebox? Didnt find any docs
# Sep 30th 2016, 17:45 wouter0100 Hmm, yeah. Thanks, I'll dive some more into it myself, :-)
# Sep 30th 2016, 17:43 inoas I still don't know enough about the schema requirements to be of help
# Sep 30th 2016, 17:42 wouter0100 Hmm, thx. I want to seperate the subscription stuff from the product tables, so I'm able to build a centralized place to manage all the subscriptions form the user.
# Sep 30th 2016, 17:42 inoas e.g. buildRules
# Sep 30th 2016, 17:42 inoas in general I think you can do complex rules within... well rules
# Sep 30th 2016, 17:41 inoas but maybe that helps
# Sep 30th 2016, 17:41 inoas I have no clue about STI and CTI
# Sep 30th 2016, 17:41 inoas question is why you want to do that ;)
# Sep 30th 2016, 17:41 inoas if you insert the keys manually it should
# Sep 30th 2016, 17:41 inoas maybe in one atomic update
# Sep 30th 2016, 17:41 inoas not sure if it works with auto increment
# Sep 30th 2016, 17:40 inoas but if you do foreign key enforcement by the database
# Sep 30th 2016, 17:40 wouter0100 I want to abstract the subscription from the Product1 and Product2 tables, because I'm going to create much more products.
# Sep 30th 2016, 17:40 inoas you simply put the foreign keys in both tables
# Sep 30th 2016, 17:40 inoas Well you can do A hasOne B + B hasOne A
# Sep 30th 2016, 17:39 wouter0100 I've currently stored the product type (eg. Product1 or Product2) together with it's ID in the subscription, but I don't know how to set this up in Cake so it's able to understand the relation.
# Sep 30th 2016, 17:38 wouter0100 Yeah, something like that! And Product1 hasOne Subscription.
# Sep 30th 2016, 17:38 inoas Subscription HasToHave(Product1 XOR Product2)?
# Sep 30th 2016, 17:38 inoas you want to be xor?
# Sep 30th 2016, 17:37 inoas don't really understand the hasOne question
# Sep 30th 2016, 17:37 inoas documents(id, revision_id), elements(id, revision_id) documents BTM elements ON document_id, document_revision_id, element_id
# Sep 30th 2016, 17:37 wouter0100 Is there any way to create 2 hasOne's to eachother, but 1 could be to another table? For example, a Subscription has one Product1 or Product2. And Product1 has one Subscription and Product2 has one Subscription? How to implement this the right way?
# Sep 30th 2016, 17:36 inoas We could use in an asymmetrical BTM assoc
# Sep 30th 2016, 17:35 inoas Question: Would targetBindingKey for belongsToMany be a good idea?
# Sep 30th 2016, 17:35 inoas today we learned alot about crud and the orm in our office - cause we had to ;)
# Sep 30th 2016, 17:34 inoas I really don't like for instance the cakephp time stuff having traits mixing static and non static, maybe even abstract and non abstract functions
# Sep 30th 2016, 17:34 inoas I'd just be careful with traits
# Sep 30th 2016, 17:34 inoas even then you can create classes instead of traits @ attaching them... but only via the callbacks basically
# Sep 30th 2016, 17:33 watermark thanks for the input
# Sep 30th 2016, 17:33 inoas but behaviors come with loading multiple files
# Sep 30th 2016, 17:33 inoas well I don't really know tbh
# Sep 30th 2016, 17:33 hmic and if you need/want to attach them to very different kind of classes too (like a controller *and* a table, think of configtrait or logtrait)
# Sep 30th 2016, 17:33 inoas yes traits are faster
# Sep 30th 2016, 17:33 watermark I assumed traits would be faster and didn't see any reason to favor a behavior (in most cases)
# Sep 30th 2016, 17:32 inoas share a function across two classes that already inherit from different classes etc
# Sep 30th 2016, 17:32 hmic as mixins, like inoas said, they are good too
# Sep 30th 2016, 17:32 hmic so for very simple things, it might be a trait
# Sep 30th 2016, 17:32 inoas I like to use them when I want multiple inheritance
# Sep 30th 2016, 17:32 hmic watermark, traits are "smaller" usually. less overhead