On Wed, Aug 25, 2010 at 4:00 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Wed, Aug 25, 2010 at 2:04 AM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> Firstly -- Nobody has ever committed to getting Alex's query-refactor >> branch merged in for Django 1.3. In fact, I'm on record in at least >> one forum (DC.eu) saying "Almost certainly not before 1.4". As Alex >> described in his end of GSoC announcement, there are still some loose >> ends that need to be resolved, and the timeframe for the 1.3 release >> doesn't provide enough time to get this stuff merged in time for a >> feature freeze. > > The only big issue I can see is AutoField.
It's certainly the biggest issue, but it's not the only issue. You're also ignoring the other side of the equation. Fixing the problems in the query-refactor branch will take a certain amount of time. There are many other ideas competing for time for the 1.3 release. Something has to give, and given the general priorities for the 1.3 release (i.e., addressing the bugs and minor features that didn't get enough attention during the 1.1 and 1.2 release cycles), bigger features with outstanding design issues are taking second priority for me. > It doesn't really matter if > the first release of Django has ListField support for PostgreSQL. What > matters is that nonrel backends have ListField. Even EmbeddedDocument > is not a MUST for the first release. Says who? Non-relational datastores store data in a fundamentally different way to relational databases. I want to know that whatever API we provide will be rich enough to encompass commonly used (and backend-appropriate) data modelling techniques. > The point of the first release is > to start the community building process, so at the time of the 1.4 > release you have enough people and enough features. Again: Says who? I'd say the point of the *development* process is to start the building the community. The point of the first release is to put something in the water that can be used for some practical purposes. c.f., Multi-db as delivered in 1.2. It isn't perfect. However, it does provide the tools necessary to build real systems and solve real problems. I have a reasonable degree of confidence that the problems that exist can be solved without fundamentally changing the API that has been delivered. > You can label this > as the low-level preparation towards full nonrel support with the > purpose of attracting backend authors for 1.4. Please don't wait until > it's perfect and you have 100% features because (1) then people will > have a nice ORM, but no backends, and (2) you'll be developing the ORM > almost "blind" without real-world feedback. Fix AutoField and get this > thing out, so people can give you real-world feedback and start > writing backends. I'm not waiting until it's perfect. I'm waiting until I have the confidence that we're going to be able to meet the needs of the various non-relational stores. MongoDB, CouchDB, GAE, and Cassandra all have different ways of looking at the storage and retrieval problem. I want to be confident that whatever solution we deliver, it will be *possible* to solve represent those partitioning techniques (or, if there is some limitation, that we know and have accepted that limitation a-priori). This is all a function of our backwards compatibility guarantee. Once we publish an API, we don't change it. That means we need to get it substantially right the first time. At the very least, we need to understand the problems that we haven't solved, even if we haven't actually solved them yet. >> Secondly -- One of the reasons that this isn't going to happen for 1.4 >> is that we're not going to rush it. Aside from fixing the loose ends, >> we need to be convinced that the changes that Alex has made are >> sufficient to support multiple non-relational backends. So far, he's >> got a compelling proof of concept with MongoDB; however, I need to see >> similar proofs of concept for other stores (CouchDB, Cassandra and GAE >> would be my ideal list) before I'm convinced that the proposed changes >> are sufficient. > > As Alex' MongoDB backend demonstrates, all nonrel backends can > retrieve the Query's filters. No - Alex's MongoDB backend demonstrates that the basic query requirements of MongoDB can be met. > With this they can fetch or count the > matching entities. What kind of problems do you expect with other > backends? I don't know. That's why I want a proof of concept. One rarely expects unexpected problems :-) > I can port the GAE backend pretty quickly if this is a prerequisite to > getting it into 1.3. As I said in my last mail, getting this into 1.3 is *highly* unlikely. I have limited time to volunteer to the 1.3 timeframe. I have a couple of larger features that I want to address. These are features that I personally see as a higher priority than non-relational datastore support. I also have a backlog of bugs and minor features that I want to address. Unless I magically find myself with a lot of free time in the next month or two, I wouldn't count on inclusion in 1.3. > But I really don't see why yet another backend > (after the GAE backend port) would make you more convinced. The ORM > merely needs to provide the filters and the backend merely needs to > provide the result rows. All of this already works. I'm glad that you're so confident about that. I'm not. You -- and the rest of the non-relational community, with expertise in other data stores -- need to prove to me that you're right. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
