Just wondering what other people are doing with regards this. I’ve been really pleased with Yii so far, by far the best framework I’ve worked with in PHP. Regular updates are great and my version runs on the bleeding edge most of the time.
I have however found a couple of bugs (Issue 3023 and Issue 3097) I’ve fixed these on my local version and have the patch files saved just in case. I don’t expect these to be integrated into the Yii source but I hope they will that’s up to the devs. If they’re not however, what method have people found best to manage their local versions?
There’s always the option of storing the patch files and applying them for as long as they’re applicable to the source whenever I update. Or the one option I’m considering where I maintain my own mercurial based Yii source, update it from SVN source and therefore can keep my patches applied and under distributed version control (quite important with lots of different instances running)
Some might say I should just override the classes and change the code there, and tbf with only about 5 lines in total changed it’s a viable solution, but it’s not really scalable if there are more and more bugs and it’ll get messy indeed overriding so many classes and copy-pasting code.
First Issue: I could add the index but it would have to be on an arbitrary auto inc. field which could cause me problems with DB portability on the tables it applies to. So it would be a bigger issue than just not dealing with the primary key. Like I say in the report though, I don’t know enough of Yii internals to have tested that fully, but it’s worked since reporting it.
Second Issue: I may be able to but for one thing it converts all + to spaces, which I would then have to convert back again because it a lot of cases, I need the +. That was only the start of the issues with double decoding it and it seemed logical to have a flag to say "leave my URL alone", could perhaps have it per URL rule instead like urlSuffix?
You need to understand one thing… if every user would add an option / method to the yii core that solves his problem… than yii would not be what it is currently (light and fast)… and something to be added to the core, needs to have a reasonable usage.
First issue:
I don’t see how would it cause you DB portability problem if you just include a new field “ID integer autoincrement”… that is a common field that I personally add to all tables (but that is my thing) … anyway this field comes very useful when you need to update or delete a certain row, and IMO you will have more problems without it than with it.
if you just add that field, you don’t have to use it at all… yii will use it for his needs.
Second issue:
This is not at all a common usage… I’m not sure who else would need this option… you did not explain your usage and why would you need the encoded url but I’m sure there is another solution to this… you just need to be more clear about what is your need and what you want to do…
I’m not sure if this helps you but for example to get the request as it is you can use Yii::app()->request->requestUri
The database thing is simply because it’s shared across a few instances that all deal with the data by adding to it, it is then culled by another process. So auto increments would be out of line between different instances. Yii doesn’t really need a primary key anyway now it has the FK=>FK option on a relation so I can specify which columns to join on.
With the URL it is quite simply that I’m processing names from the URL against the database, we want a “-” as the space and not the “+”, the fix was to stop the decoding before we got hold of it in params. Looking deeper it could probably go back to being a custom url rule class like it was a few iterations ago, and could probably stop using getParams() and use the requestUri like you suggested. It’ll change further down the line multiple times I would imagine before we get the specs exactly right.
Anywho… this is exactly my point, I don’t expect you to integrate my fixes, you have perfectly good reasons not to. I submitted them because I had already applied and roughly tested them and hoped they might be useful to others, I’ll continue to keep them locally as long as I need them. But my original point was to find the best way to do this.
I’m not sure about which instances you are talking… but the autoincrement is handled by the database engine itself… so in that regards there is no problem about handling it… you just need to insert the other fields… you don’t give any value for the ID field… the database will handle that.
for the URL… you want to stop decoding so that you can change the + to -… but you can just get the unencoded string and change the spaces to a -
