Old time programmer (since 1979) and fan of PHP (since '97) who decided to venture out and see what all the fussing over the OS frameworks was all about. I was enticed by a PHP Magazine article on CakePHP and after reading a lot of the pros and cons of different frameworks this seemed like the best fit so what I wanted to try out. For my first project I decided to take a database from an older site I was thinking of revamping anyways. Turns out I ran into problems right away because Cake does not support a multi-column primary index. Ouch, I use these a lot and so do a lot of programmers I know. Rather than just deleting Cake and moving on to try another framework. my curious nature got me interested as to why this was.
I found a number of discussions on this and honestly what I found disturbed me. A number of the responses were very obvious that the poster has a very limited understanding of relational databases, they had no clue as to the difference between a key and an index, and could not grasp why anyone would want this and thus deemed it as unimportant. My concern is these posters were posing as CakePHP experts. Being an old timer in the greater programming community (since '79) I do fully realize that upon entering a new community (CakePHP) that there are going to be experts and the usual vocal wannabes and so I took this with a grain of salt. However then I came to https://trac.cakephp.org/ticket/1293 Here this feature was requested by a couple of folks. The developer "nate" responds to the first requester by saying this is definitely not the direction they want to take CakePHP in but gives no other reason why. The second requester sees what I see in that it doesn't look like they think it is important so he re-opens it mentioning that it is important enough that ZF supports this. The same developer not only shuts it down but minimizes it to trivial and warns the guy about ever mentioning ZF. I've not looked at ZF personally but is it not open source and if there are good ideas in it is it not okay to adopt them, after all isn't CakePHP isn't original but based strongly on Ruby on Rails from what I understand. So from the outside, what am I to assume? No real reason is given for CakePHP not supporting this and by the way it is closed down it is like they don't even want to ever consider supporting a database table's multi-column primary index as a key, even though the SQL databases CakePHP supports do support this and recommend it for optimized SQL setups. Shutting it down without an explanation gives the impression it was beyond the developers comprehension as otherwise why wouldn't they explain it. Who knows, perhaps the developer did explain it offline and had a very good reason, perhaps he was having a bad development day and couldn't handle someone comparing his software to a competitors, or perhaps the person requesting this was annoying to the group and they were tired of answering them. With what is posted however, I hope you can understand why as a newbie to CakePHP I have my concerns. I can only take it as I read it posted by the developer where they are not interested in taking CakePHP in this direction. So now I'd like to know why before I throw any real support behind CakePHP. Database development years ago worked hard to add this ability for performance and integrity purposes so why would CakePHP not take advantage of that strength in the supporting database. The suggestions I found on the various CakePHP posts I could find was to add a new field to these tables and make it the primary index/key and then take the other existing tables (that used to make the primary multi-column index) and make them into a unique key. To a database a primary index is always a unique key whether it is multi-column or not so it seems like a huge waste of resources to have an extra redundant resource. It'd be like adding a birthdate and age column to the same database only with a bigger performance hit. This got me curious, I know it used to be significantly faster using multi-column indexes (thus why databases added this ability) but having not tested that in years I ran some benchmarks just now. Inserting 1 billion records took only 1 second longer on average when having the two indexes as the CakePHP posts suggested I convert them too. Yet they all took exactly twice the amount of disk/ram space. Thus as I expected, SELECT queries on the other hand did see a performance hit compared to data stored with one multi-column primary index. But it wasn't a huge hit. Having not looked into the bowels of CakePHP and how it does it's object relational mapping I can only guess it is not being done because it is either too much work for a small performance gain, or the extra overhead the CakePHP model objects need to handle this out weight the performance gains. If anyone has the actual reason of why CakePHP won't consider this I'd greatly appreciate it. I only felt it important to give feedback as being a developer myself I want to know when my community is interpreting what we are doing as developers. In looking for the answers I found more people bickering about lack of communication than anything else so I hope this helps. On a more positive note, I am very impressed with what I see so far. There are some real perks, I especially like the bake cli allowing me to do a quick though dirty setup. My fear is I'll more likely forget to go back and add something that is really important. I'll know more in a few days how easy it is to customize it to get it to flow the way I want (as I'm currently only using the scaffolding). I know using a framework will have a performance hit but for many applications that is not important, though I hate to say that as I believe too many developers have heard the "processors are cheaper than developers" theory one to many times and then we are stuck with things like Vista. I look forward to the next few days when I have more time to get into the depths of CakePHP. Jay --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
