"When it did work it would return enormous nested arrays of data causing massive CPU and memory usage (out of memory errors plague us on AMO). When it didn’t work, we’d end up doing queries directly which kind of defeats the purpose."
For what it's worth, I believe a lot of these issues are solved with 1.2 (AMO claims to be still on 1.1 which is at least two years old now). It sounds as if their system is just defining relations in their models and letting the database layer pull up all the objects for them. Which of course creates problems. They should shift to using "contains" to limit the depth of the objects retrieved.
The only real issues I've run into in the most recent version of Cake have been an inability to define a separate join table on one of the basic relationships (hasMany?). I seem to remember rails making this possible through an intermediary table, but it is somewhat advanced in any case and the easiest solution ended up being to write an SQL function in the model and use that to fetch the data. It was not hard.
Agree, it sounds like most of their issues were solved in 1.2. Huge nested arrays definitely sounds like they aren't controlling the recursion level properly, which is quite simple in 1.2 as you mentioned. Caching is also quite painless in 1.2.
Its too bad for such a high profile project to bail on Cake without giving the new version a try. It really is an excellent framework for many projects.
The reasons given in this post show the ineffectiveness of the AMO development team.
I worked at Yahoo and I’ve used different Java and PHP frameworks in the past, some good, some bad. However, that never stopped us from having a continuous build running locally and an integration build running on our server, or from unit testing our code, even though we had to extend and adapt some components and unit testing frameworks. The same with debugging, it never stopped us from creating awesome tools to debug our code and monitor the performance of our applications.
After finishing building a CMS using Django, I can only say one thing: A framework doesn't make you a better programmer. If you suck, you suck.
Didn't know they were running CakePHP, but I can understand it being insufficient. Unfortunately, its attempts to copy Rails have left it as a framework designed for the wrong language. It's OK for beginners, but not something you really want to get locked into.
I unfortunately have had way too much experience with CakePHP. It is the second to worst framework I have used. Second to .NET 2. CakePHP trying to emulate Rails while supporting PHP was an idea destined to fail especially when trying to support PHP 4.x.
Well it was originally a fork of CI. Version 2 was a recode but using the same inspiration. Version 3 is another rebuild but a more developed version of the idea (i.e. unrecognisable from it's CI origins).
It's about preference I guess: Kohana takes advantage of a lot of the PHP5 extra's and also unfucks some of the "gotcha's" CI had (especially in the area of loading stuff). Also it is updated more regularly and is community developed.
CI is still good, I personally prefer Kohana's way of doing it.
I thought it was a recent fork of the project - I stand corrected. Kohana certainly does look good. I'm just getting to grips with CI now. Authentication has been a matter of bolting on a 3rd party library. Would you recommend a switch to Kohana? I'm mostly concerned by the long-term support and development for each of them.
EDIT: Just realised that I'm asking you to sum up a lot to recommend one over the other. I'm currently looking at both in detail, cheers.
I'd recommend it yes. Kohana is a bit of a hackers framework - you do need to dig inside it sometimes (I consider that a good thing). It also has a pretty nice ORM based / Role based auth module included which you can extend fairly easily.
In terms of LTS: V2 is pretty frozen at 2.4 right now (i.e. no API changes) though the documentation still reflects V2.3. There should only be bug fixes on the 2.x branch. 3.x is in active development (and worth looking at) and should be there for the long haul.
I personally use 2.x because that is what I started with and I haven't had chance to make the switch to 3.x (it's pretty much the same except there are changes to some naming conventions and file paths) mostly due to having to support 2.x based sites still :)
I am equally surprised by both choices. I rarely visit the site consciously, but I often end up there through internal firefox redirection, say, after an automatic addon update. Given Mozilla's marketshare, a very popular addon can easily spike the site's traffic. The recent security issue removing the Microsoft .NET plugin is a good example.
Seems like they have the resources to keep php and python running under duress.
For what it's worth, I believe a lot of these issues are solved with 1.2 (AMO claims to be still on 1.1 which is at least two years old now). It sounds as if their system is just defining relations in their models and letting the database layer pull up all the objects for them. Which of course creates problems. They should shift to using "contains" to limit the depth of the objects retrieved.
The only real issues I've run into in the most recent version of Cake have been an inability to define a separate join table on one of the basic relationships (hasMany?). I seem to remember rails making this possible through an intermediary table, but it is somewhat advanced in any case and the easiest solution ended up being to write an SQL function in the model and use that to fetch the data. It was not hard.
Good luck to them with the re-write.