Re: MS SQL backend as a proper external backend (was: RFC: Django 1.0 roadmap and timeline)
On Thu, Jun 12, 2008 at 6:35 PM, Ramiro Morales <[EMAIL PROTECTED]> wrote: > Since then I've opened ticket [2]#7420 with a patch that would reduce the list > of things needed to patch in Django to just *one item: Taking in account the > fact that in pyodbc seems to be the only DB-API2 adapter where > connection.autocommit is an attribute and not a method (didn't find a way to > cleanly monkeypatch this). It's also an attribute in cx_Oracle. I'll have to take a look at it some time and figure out why it's not broken. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MS SQL backend as a proper external backend (was: RFC: Django 1.0 roadmap and timeline)
On Thu, Jun 12, 2008 at 8:35 PM, Ramiro Morales <[EMAIL PROTECTED]> wrote: > > Jack Moffitt, mamcx (and everyone interested), > > I've been working in my free time for the last few days on updating the > pyodbc-based MS SQL Server backend so it a) can be an external Django > backend and b) to post qs-rf merge. [...] > Since then I've opened ticket [2]#7420 with a patch I see that part of the patch deals with the fact that the underlying adapter prefer to receive actual date and time instances for date and time parameters, instead of strings. I have the same problem when talking to JDBC drivers. To solve it I proposed[1] another strategy: delegate type conversion to the backend. Otherwise, I think we will end with too many backend flags. You can see my first attempt on https://hg.leosoto.com/django.doj/rev/8b0c71447f98. I've made more adjustments later[2] and plan to submit a patch once I fix all the remaining backend related test failures with postgresql_zxjdbc (Which, according to my schedule should be this week) This won't help with the interprets_empty_strings_as_nulls flag you are proposing, tough. > that would reduce the list > of things needed to patch in Django to just *one item: Taking in account the > fact that in pyodbc seems to be the only DB-API2 adapter where > connection.autocommit is an attribute and not a method (didn't find a way to > cleanly monkeypatch this). You are definitely not alone. Same happens with zxJDBC. Same workaround as yours: https://hg.leosoto.com/django.doj/rev/235b40d3da2e [1] http://groups.google.com/group/django-developers/browse_thread/thread/fb1afa93451008a2/0fed055c00cb64e7 [2] https://hg.leosoto.com/django.doj/log?rev=leo.soto+get_db_prep -- Leo Soto M. http://blog.leosoto.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
MS SQL backend as a proper external backend (was: RFC: Django 1.0 roadmap and timeline)
Jack Moffitt, mamcx (and everyone interested), I've been working in my free time for the last few days on updating the pyodbc-based MS SQL Server backend so it a) can be an external Django backend and b) to post qs-rf merge. First I tried to participate by testing django-pyodbc and opening a [1]ticket about missing files in the repo in the the project issue tracker but later found the code there does not add much to what Filip Wasilewski had already implemented on #5246 and in fact has more serious problems. Since then I've opened ticket [2]#7420 with a patch that would reduce the list of things needed to patch in Django to just *one item: Taking in account the fact that in pyodbc seems to be the only DB-API2 adapter where connection.autocommit is an attribute and not a method (didn't find a way to cleanly monkeypatch this). Hopefully, this will help clear the way to get this backend closer to completion, exposure and much needed testing and feedback by users without forcing them to touch Django core code and without the need to pester Django devs to give official support and infrastructure. What are you opinions about this? Do you think a collective effort can be made?. I'm learning my way in the internals of Django and have a very basic knowledge of SQL and SQL Server but I could make use of such a backend plus Django trunk for some work and personal projects. Regards, * Perhaps I would also need to open a ticket for this 4-line test/utils.py [3]modification. -- Ramiro Morales 1. http://code.google.com/p/django-pyodbc/issues/detail?id=1 2. http://code.djangoproject.com/ticket/7420 3. http://code.djangoproject.com/attachment/ticket/5246/mssql_pyodbc.2.patch --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
+1 on trac milestones. I think it's important that people start to see what will be done when and what features will get pushed off to 1.0. Milestones, at least for me as a growing developer, have always provided that extra motivation as the progress meter approaches 100%. Just seems more organized too. On Jun 12, 2:29 pm, mrts <[EMAIL PROTECTED]> wrote: > I'd like to bring up trac milestones again. > > Currently Django has over 1000 active tickets. Some of them are > relevant to oldforms-admin, some are from pre-qsrf merge, some are > features for 1.1. But quite a few are small bugs that should be fixed > before 1.0. > > Putting up milestones in trac would spark a community effort to sort > them properly. Assuming one minute per ticket, the sorting alone takes > 17 hours from a single person. Hence community effort is clearly > required. Having a defined ticket set for 1.0 and all the intermediate > alphas is very important IMHO and using a single VersionOneFeatures > wiki page for that is practically impossible. That page is great for a > general vision and major issues that span tickets, but as I said, we > have to deal with the multitude of small issues as well. > > Milestones should be set up according to Jacob's post (+ a legacy > milestone, e.g. 0.96-legacy for capturing tickets that are made > irrelevant after nfa merge etc). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Admin media handling #7129
Hello, I need to draw some quick attention to media handling in newforms- admin. Ticket #7129 [1] was opened with the intension of the old admin's behavior with the js inner Admin option. The trunk documentation states: If you use relative URLs — URLs that don’t start with http:// or / — then the admin site will automatically prefix these links with settings.ADMIN_MEDIA_PREFIX. However with the use of the new Media class the default behavior of relative paths will prepend settings.MEDIA_URL. I am wondering if the change to force an explicit prepend of ADMIN_MEDIA_PREFIX is now the requirement on newforms-admin? Should the admin handle media slightly different or should there be note in the docs about this? When the media handling code landed there wasn't any docs in regard to the admin specific handling of media, it was just implied from the regular media handling code for newforms. [1]: http://code.djangoproject.com/ticket/7129 Thanks, Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
As one of the guys that try to do the MS-Sql part: http://code.djangoproject.com/ticket/5062 I must say that I sell a internal semi-store with that code, integrate later http://code.djangoproject.com/ticket/5246 and work fine. But feel that the django people discourage the work at all. First, to get this work is necesary put some lines in the core files of the DB side. And later, that get erased, so is necesary do patching, and patching not work because if we need do svn update to get something fixed the work get lost. Patching is not fun with a project working only in numerical revisions. Then, other start the project and remove the good work that tickets do (using a module workable on linux, doing paggination - is a complete MYTH that is impossible in sql server - and stuff like that) and that is depressing. Plus none of the actual code on google work at all... *IF* the small but necesary modifications to the core DB files get there - seriously, some fix bad assumptions or simply ad "if is msssql" - I can do the mssql engine itself. In fact 5246 & 5062 are coded in similar ways to the oracle backend. --- In short the only & only thing pushing this back again and again is that until now is necesary patch the core django. Tell me how that could be avoided, and the mssql integration can be done very fast. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
Ville Säävuori wrote: > The point of deadlines are that people tend to try to make them come > true. If there is something that I've learned as a project manager > during all the years that I've worked as one, it's that deadlines are > important. My main point was that the deadline should be real. Failing that, having no deadline is just better than having a false one. However Jacob have already cleared up that early September wasn't chosen arbitrarily so there's no argument anymore. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
#3591: add support for custom app_label (and verbose_name?)
As proposed by mrts, I'd like to take the discussion from #3591 [1]
here.
A note on InstalledAppsRevision [2]: I like most of it (especially
`db_prefix`) but cannot see the value of having multiple instances of
the same app. Is there an example that illustrates why this is needed
(everything I can come up with is basically a design flaw)? And you
would have to tell each 3rd party app with dependencies which
instances to use.
Meta data in App: There will be lots of useful meta data (weight,
description, style, short_description, icons, ...) cluttering App and
preventing multiple AdminSite instances from using different meta
data. I could accept verbose_name (if nfa doesn't remove it from
fields), although it just doesn't feel right.
Something like `AppAdmin`[3] would play nice with multiple AdminSite
instances and enable apps to provide default meta data (subclass it
as needed).
I have another proposal which I originally wanted to defer until I
could offer some code (and some form of App has landed in trunk):
include app specific settings
App('mypkg.myapp', 'myapp', settings = 'somepkg.settings.myapp')
accessible through `from mypkg.myapp.conf import settings`. I bring
this up now, because it could be (ab)used to provide app meta data
without cluttering App. Just reserve settings like _NAME,
_DESCRIPTION, _ADMIN_WEIGHT, ..
Optionally: move settings.py to settings/__init__.py and look for
settings/.py automagically.
[1] http://code.djangoproject.com/ticket/3591
[2] http://code.djangoproject.com/wiki/InstalledAppsRevision
[3] http://code.djangoproject.com/ticket/3591#comment:38
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
I'd like to bring up trac milestones again. Currently Django has over 1000 active tickets. Some of them are relevant to oldforms-admin, some are from pre-qsrf merge, some are features for 1.1. But quite a few are small bugs that should be fixed before 1.0. Putting up milestones in trac would spark a community effort to sort them properly. Assuming one minute per ticket, the sorting alone takes 17 hours from a single person. Hence community effort is clearly required. Having a defined ticket set for 1.0 and all the intermediate alphas is very important IMHO and using a single VersionOneFeatures wiki page for that is practically impossible. That page is great for a general vision and major issues that span tickets, but as I said, we have to deal with the multitude of small issues as well. Milestones should be set up according to Jacob's post (+ a legacy milestone, e.g. 0.96-legacy for capturing tickets that are made irrelevant after nfa merge etc). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
Jacob, I feel your pain butty. Do what you think is right, django has been brilliant so far. The jump to version 1(lightspeed) has been a bit of a nightmare, but let's all remember a pre django world. I for one trust Jacob's judgement. Just do it mate, there's good good people who want to help. Chewie fixed the falcon with a blow from a spanner. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django development staleness
On 11 Jūn., 03:45, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Wed, Jun 11, 2008 at 6:46 AM, Edgars Jēkabsons > > <[EMAIL PROTECTED]> wrote: > ... > > I understand that I can help by triaging the 341 unreviewed, I can't > > at the moment imagine doing design decisions in the name of the > > community though. > > This is a triage process - we're not asking you to make decisions for > the community - we're asking you to filter the fire hose of tickets > and give us a trickle we can manage. Well, the contributing information contains the following text as exit for design decision needed marked tickets - "The community and/or core developers decide whether this ticket can and will be fixed". Seeing that there are >200 tickets waiting for "the community and/or core developers" to decide surely I'd like to help. > It also calls for volunteers. These tickets don't fix themselves, and > you don't need a formal invitation or sprint to give you permission to > work on them. The Django contribution guide [1] contains more details, > but there is lots you could do to help out: > > > [1]http://www.djangoproject.com/documentation/contributing/ Ironically http://code.djangoproject.com/ticket/6320 that improves the contributing information is marked as design decision needed with no progress for 5 months. Am I allowed to mark it as ready for checkin? Best regards, Edgars --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
> So what's the point of hoping for September if it's not real? The point of deadlines are that people tend to try to make them come true. If there is something that I've learned as a project manager during all the years that I've worked as one, it's that deadlines are important. Its not as important *when* the deadline is, as long as there is one. If the proposed timeline is in the lines of "it would be great if we would have 1.0 by the end of this year", we'll still be having this same conversation about deadlines next year at this time :) - VS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
On Thu, Jun 12, 2008 at 11:10 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > And this is great of course. But having to develop externally away > from the many eyes of the Django community is sort of an impairment. > It's a lot easier to get traction on a project that is in the Django > repo somewhere than to get it for a project on Google Code. If somebody wants a branch in which to do the work, I wouldn't have any problem setting it up; that's how we did it for Oracle, and merged it back to trunk when it was ready. > No one says the Django team must exhaustively maintain every bit of > code in the repository. Surely it is quite easy to not include MS SQL > in the default list of backends and/or mention in the documentation > that MS SQL support is unsupported and experimental until such time as > it improves. Plenty of projects have bits of code that are crufty and > get labeled as such, and don't burn cycles maintaining it themselves. Having dead, non-functional code in Django is something I'd like to avoid. And there's a world of difference between "here's an experimental feature" and "here's something that was abandoned by the person who developed it, and we don't know much about it". -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
On Thu, Jun 12, 2008 at 16:39, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On Thu, Jun 12, 2008 at 3:32 AM, Gábor Farkas <[EMAIL PROTECTED]> wrote: >> >>> 5. Model-level validation (#6845). > [...] >> and i thought it's in the plan to have this in 1.0. > > It is, assuming it gets done. Last I check Honza was working on it, > and if he's still interested I expect he'd be able to wrap it up. > However, while it would suck to ship 1.0 without it, there's nothing > about the API that has to be backwards-incompatible, and it's a > potentially "dangerous" feature in that it could spawn a lot of work. > So, if we can get there, great; if not, well, you've got a reason to > look forward to 1.1 :) I will be around at europython with few people from our team and we will try hard to finish the patch, along with anything we can contribute to nfa since we use that A LOT ;). I will also be giving a talk at EuroPython on newforms-admin. 80% of the work is done, I believe, and time has come to test that. I strongly believe that it should be part of 1.0, because it can change the behavior of the models (if not the entire API), since now you can do pretty nasty stuff to the models without anybody noticing and applying it later might thus create some nasty backwards-incompatible changes. Right now I would appreciate any help from the general public in testing the feature set and the design principles. The patch is far from complete, but the main ideas are there. I have attached a new version of the patch to the ticket. >> so i wonder, that if the WSGI-conformance ticket is a must-have, then >> why this isn't too... >> >> perhaps the WSGI-change is smaller... > > Exactly -- the WSGI change is very small, and actually done (see the > latest patch on #295). It basically just needs to be applied. > >> anyway, would be great to have the how-can-we-help data >> (liutenant/committer/etc) >> published as soon as possible... > > Yup, that's the next step! count me in for #6845. Since the timeline is finally up, I can set aside some time each day for work on this feature. > > Jacob > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
Honza Král E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 On Thu, Jun 12, 2008 at 10:32, Gábor Farkas <[EMAIL PROTECTED]> wrote: > > On Thu, Jun 12, 2008 at 4:03 AM, Jacob Kaplan-Moss > <[EMAIL PROTECTED]> wrote: >> >> "Maybe" features >> >> > . > . > . >> >> 5. Model-level validation (#6845). > > hi, > > it always seems quite ugly, that you can create a model with invalid data, > and save it. so when you want to validate it's content, you have to hack > around > and create a form for it, etc... > > as far as i understand, this change is a backwards-incompatible change, > and also touches quite the basic parts of the whole > models/forms/validation system, > > and i thought it's in the plan to have this in 1.0. > > so i wonder, that if the WSGI-conformance ticket is a must-have, then > why this isn't too... > > perhaps the WSGI-change is smaller... > > anyway, would be great to have the how-can-we-help data > (liutenant/committer/etc) > published as soon as possible... most of the tickets mentioned were assigned to someone. I am the one working on 6845 and the how-can-anybody-help is attached to the ticket: the missing parts: 1. *feedback* !! (works, does what everybody expects it to do, has all the options neede) 2. *documentation* and code clenup 3. tests (the existing tests were adapted, but more are needed) > > gabor > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
On Jun 12, 8:51 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > On Thu, Jun 12, 2008 at 7:06 AM, Forest Bond <[EMAIL PROTECTED]> wrote: > > I think that this is a must-have: > > > #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff > > Then you'll be glad to know that it's #3 the list of "Must-have > features" in Jacob's email, just a bit below the portion you quoted. Indeed. Don't know how, but I mis-read that. Sorry. -Forest --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: One more issue with file storage
Le 9 juin 08 à 19:11, Marty Alchin a écrit : > I've been fairly quiet on the file storage front for a while, since > it's basically done now, and is just waiting on the streaming upload > ticket to hit trunk first. Since I got to that point, however, I've > had two different people, working on two different storage backends, > both approach me with the same question. It doesn't seem like a > showstopper to me, but I'd definitely like to get it addressed. I've > been mulling it over for a while now and can't come up with a > universally "good" solution, so I'd like to bring it to the group for > discussion. Unfortunately, I hadn't found any elegant solution since our last discussion. > * Storage systems take the name that the model knows about and maps it > to an actual storage mechanism. This way, each site is free to decide > how and where its files are stored and retrieved, independent of any > specific model. About Storages, I eventually setup a repository which is more flexible than ticket #6390 http://code.larlet.fr/django-storages/ There is already the S3 one and I'll work on the FTPStorage soon. Hope it helps, let me know if there are other storages in progress. Cheers, David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
> > The schedule looks good. I think you should be hardlined about the > > dates and not as hardlined on what makes it in. > > That's the plan. Only the "blocker" features actually can delay the > release, and I expect them to be done (sans bug fixes) by that alpha > date. What I meant was, if the blocker features are late, do another alpha release instead of having a giant block of time with no external releases. So the 1.0 may slip a week, but at least the world knows that it is moving forward as fast as ever. Hopefully it won't be a problem at all :) jack. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
On Jun 12, 4:43 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > On Thu, Jun 12, 2008 at 8:42 AM, Remco Wendt <[EMAIL PROTECTED]> wrote: > > Will the API be frozen from the alpha release? Or is this a beta > > release thing? > > I'm not sure... I think probably beta 1 should be the API freeze, but > it's possible that with all the new features due at that point we > might need to tweak the APIs to fix bugs afterwards. I'd say that best > plan should be that any backwards-incompatible API changes after beta > 1 need a quick discussion here; sound good? Well personally I would push all the API changes for the alpha release. And from thereon shift towards stabilizing the API by giving people as much time as possible to test and debug (before the final release). The more you push the API freeze towards the final release, the less time people have to test against a stable API. But I honestly don't know whether this is a feasible option. So other people will have to respond to this. > > Also I it may be interesting to show some love to the sprintideas page > > (http://code.djangoproject.com/wiki/SprintIdeas). And get a wiki page > > up for the Europython sprint (I couldn't find it). If you want me to > > take care of this stuff, let me know. > > That would be awesome -- thanks! Excellent! I'll put it on my list for this week. Remco --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Introducing ModelView, a RESTful class-based view of your resources
Le 9 juin 08 à 13:52, David Larlet a écrit : > > Le 8 juin 08 à 16:11, Ivan Sagalaev a écrit : >> >> David Larlet wrote: >>> This is not a secret that I'm interested in both Django and Semantic >>> Web. I'm following discussion about Django+REST for more than two >>> years and when I realize that newforms-admin branch will use class- >>> based generic views [1], I decided that it's probably the right >>> moment >>> to do something with that. >>> >>> [1] http://code.djangoproject.com/ticket/6735 >> >> David, this is a good news for us REST-fans :-). However don't you >> think >> it could better start living as a separate app? It could get some >> early >> adoption without needing to pursue inclusion in trunk. > > Of course, I just want to know if it could be possible as a middle- > term goal because it doesn't involve the same energy if it's for me, > a couple of REST-fans or the trunk (for example, tests and > documentation are not exactly the same). > > Anyway, I'll setup a repository and add some generic tests, that's > the minimum. Here it is: http://code.larlet.fr/django-modelviews/ (at least for the first part). I'll setup the base architecture but feel free to participate, push access is granted for all. Cheers, David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
> > I have to ask why must Django prevent work in this regard? > > To be perfectly fair, it's not really "prevented". Django supports the > use of database backends not defined in Django itself, so third-party > development of backends is unimpaired. And this is great of course. But having to develop externally away from the many eyes of the Django community is sort of an impairment. It's a lot easier to get traction on a project that is in the Django repo somewhere than to get it for a project on Google Code. > And for the one most people > mention wanting -- MS SQL -- I think that's a good idea; that backend > has a history of people stepping up, putting in a burst of work and > then fading away, leaving the code dead and the Django dev team > responsible for maintaining it as long as it's in Django's codebase. No one says the Django team must exhaustively maintain every bit of code in the repository. Surely it is quite easy to not include MS SQL in the default list of backends and/or mention in the documentation that MS SQL support is unsupported and experimental until such time as it improves. Plenty of projects have bits of code that are crufty and get labeled as such, and don't burn cycles maintaining it themselves. To give a concrete example, the Xiph.org repositories have several experimental codecs that are completely abandoned (unless someone shows up to hack on them). We leave them there because they show people that we foster creativity and community contribution, and there are many good ideas there that should be kept around for reference. And who knows, someday the guy who worte most of the Tarkin code may come back and give MPEG-4 video a run for its money. But he certainly won't if we just throw out his code. Communities are inclusive. > What really needs to happen there is much the same as what happened > with Oracle: some people who are really clamoring for it need to > organize and start pooling their efforts to develop something that can > comfortably become a part of Django (and now that external backends > are supported and qs-rf made the underlying mechanics of custom Query > classes much simpler, anyone wanting to do a new backend probably > faces a much easier time of it than the Oracle folks did). The problem here is that it may take more than just one dedicated maintainer. By forcing the project outside the codebase, you've eliminated (almost) the possibility of a bunch of random people helping a little bit and getting the code in shape. It may be that there won't be some dedicated single person who is willing to champion this. But I bet there are a lot of people who are willing to help. If you search on MS SQL support and Django, you find people talking about how it doesn't work because of pagination problems. If you search on RoR and MS SQL support, people are talking about the best ways to do replication. It would be good for the project to attract the poor developers using MS SQL (not by choice in many case) who work at corporations and academia. I know people at the University of New Mexico who would love to use Django, but the only requirement it must fulfill is MS SQL support. Neither they nor I have the time to invest to make MS SQL support happen, but removing MS SQL support from the repository makes them think Django doesn't. When it was not working so great, but still included, at least they had hope that by the time they were ready someone would have fixed it. jack. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Is there a django meta model ?
I dont' think it's a usage question about Django. Django has a coding paradigm. Availability and usage of a meta model would permit to have a configuring paradigm and would make django generation easier. The development of django itself could be impacted. PS: I will post my message on user list. JC Collin Grady a écrit : > Jean-Christophe Kermagoret said the following: > >> I need this meta model to generate automatically django code from models. >> >> If there is no meta model, is there presently some code which would >> permit to have code automatically generated from xml (or properly >> properties) configuration files ? >> > > Usage questions like this belong on the django-users list :) > > This list is for the development of django itself. > > -- Jean-Christophe Kermagoret Directeur associé BlueXML 40, bd Jean Ingres 44100 Nantes Tél : 06.08.56.83.80 BlueXML : http://www.bluexml.com OpenBlueLab : http://www.openbluelab.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: get_{next,previous}_by_someDateField()
El mar, 10-06-2008 a las 09:54 -0400, Karen Tracey escribió: > I agree the error message could be better. > Thanks for the elaborate and concise answer, I'll work on a nicer error message then ;) Should the error raise a ProgrammingError or ValueError ? -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: RFC: Django 1.0 roadmap and timeline
On Thu, Jun 12, 2008 at 8:42 AM, Remco Wendt <[EMAIL PROTECTED]> wrote: > Will the API be frozen from the alpha release? Or is this a beta > release thing? I'm not sure... I think probably beta 1 should be the API freeze, but it's possible that with all the new features due at that point we might need to tweak the APIs to fix bugs afterwards. I'd say that best plan should be that any backwards-incompatible API changes after beta 1 need a quick discussion here; sound good? > Also I it may be interesting to show some love to the sprintideas page > (http://code.djangoproject.com/wiki/SprintIdeas). And get a wiki page > up for the Europython sprint (I couldn't find it). If you want me to > take care of this stuff, let me know. That would be awesome -- thanks! Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
On Thu, Jun 12, 2008 at 3:32 AM, Gábor Farkas <[EMAIL PROTECTED]> wrote: > >> 5. Model-level validation (#6845). [...] > and i thought it's in the plan to have this in 1.0. It is, assuming it gets done. Last I check Honza was working on it, and if he's still interested I expect he'd be able to wrap it up. However, while it would suck to ship 1.0 without it, there's nothing about the API that has to be backwards-incompatible, and it's a potentially "dangerous" feature in that it could spawn a lot of work. So, if we can get there, great; if not, well, you've got a reason to look forward to 1.1 :) > so i wonder, that if the WSGI-conformance ticket is a must-have, then > why this isn't too... > > perhaps the WSGI-change is smaller... Exactly -- the WSGI change is very small, and actually done (see the latest patch on #295). It basically just needs to be applied. > anyway, would be great to have the how-can-we-help data > (liutenant/committer/etc) > published as soon as possible... Yup, that's the next step! Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
On Thu, Jun 12, 2008 at 7:58 AM, Luke Plant <[EMAIL PROTECTED]> wrote: > First, I think you meant #730 > Second, I think this needs to be a must have, or at least the current > behaviour must be *documented*. See discussion on #749 Yup, I meant #730, and I think you're right that we should figure out something to do on #749 as well. Added to the todo list. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
On Thu, Jun 12, 2008 at 5:18 AM, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Ouch... To paraphrase Joel Spolsky "If you have a hand-wavy feature > called "1.0 release" and you schedule 3 months for it, you are doomed". > Jacob, honestly, where this date has come from? It can as easily be > August or October. You've outlined a good feature list and seem resolute > to stick to it. But unless all those lieutenants would plan their > features *in work hours*, you just can't know the date. Remember back in math class where you'd get marked down despite the correct answer because you didn't "show your work"? I always hated that. Still do, apparently, because although I just threw those dates out there, I really did work very hard on them, and I do think they're feasible. First, it's not "a had-wavy feature": only the blocker items *must* be done for 1.0. So if we'll all extremely lazy, we've got one big-but-mostly-done feature (nfa), one medium-but-easy-and-also-almost done feature (newforms in generic views), and one trivial-and-done-but-not-merged feature (#285). I think it's perfectly reasonable to expect to get those done in three months, don't you? I didn't, though, just plunk a date three months out; the idea is to take about a month to get to the alpha -- that is, one month to finish the blocker features (but not necessarily make them bug-free), then two weeks to the first beta, then a week each between each snapshot until 1.0. Further, I actually *can* predict at least one person's time in "work hours": mine. Thanks to my kick-ass job, I get to spend most of my work hours on Django. On top of that, I have firm commitments to attend the sprints from a number of talented developers; I know from experience that sprints are incredibly productive. We'll have *six* of them between now and September. Now, of course only time will tell whether I'm nuts or not, but I'm pretty confidant that we can hit these dates. More important, though, is that having firm dates will force the people working on "maybe" features to put up or shut up, and it'll make our jobs as integrators much easier -- only having a handful of things to merge will make that process *much* less fraught. > So may be it's not too late to state clearly that we have a plan but > it's not a schedule. Well, I tried to do that with the disclaimer about this being a draft at the top. But, yeah, of course this is just a draft. That said, I don't hear alternate timeline proposals -- do you have one? If you do, you might want to learn from my mistake and "show your work" :) Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
On Wed, Jun 11, 2008 at 11:17 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I have to ask why must Django prevent work in this regard? It's not so much about "preventing" work -- nobody here works *for* me, and I can't really tell anybody what to do. It's more about focusing priorities. So the idea is that if someone comes along wanting to help, we can show them a todo list of features that'll actually help us hit 1.0 on schedule. If people are excited about other database backends they of *course* can work on them, but we'll simply defer discussion of including the backend in Django until after 1.0 ships. I'm OK doing this since database backends can be external (i.e. http://code.google.com/p/django-mssql/). > The schedule looks good. I think you should be hardlined about the > dates and not as hardlined on what makes it in. That's the plan. Only the "blocker" features actually can delay the release, and I expect them to be done (sans bug fixes) by that alpha date. > I would even consider dropping all but security patches to 0.96. That > is practically the limit of support anyway it seems, and is not likely > to cause much work. Good thoughts, but let's table this discussion until we actually get around to appointing version managers; if we try to tackle too much process now my head asplode. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
+1 on getting a release out there as soon as humanly possible ;) On Jun 12, 4:03 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > * An alpha release containing all must-have features, but likely not > bug-free. We'll push hard to have all the must-haves done in time > for ample testing. Will the API be frozen from the alpha release? Or is this a beta release thing? >From the must haves list it is mainly clearing the new-forms admin blockers list. So if alpha is a (soft) API freeze, do the newforms- admin people think we can work away all those tickets before july 20th? Also I it may be interesting to show some love to the sprintideas page (http://code.djangoproject.com/wiki/SprintIdeas). And get a wiki page up for the Europython sprint (I couldn't find it). If you want me to take care of this stuff, let me know. Remco --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
Ville Säävuori wrote: > Firstly, as Jacob said, the schedule is just a draft at this point. > But I'm very much +1 on locking down spesific dates for any given > milestone. It's vital to have firm schedule and dates for making it > all happen in a relatively short period of time. If this is vital (for which I'm not a great judge) then it can only happen by actually calculating the date, not just by choosing something "motivating". And calculating means that every feature should be divided into pieces that are fully designed and scheduled. It's very hard and, you know, *boring* and it's why I think nobody will do this (I wouldn't :-) ). So what's the point of hoping for September if it's not real? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
On Thursday 12 June 2008 03:03:21 Jacob Kaplan-Moss wrote: > 11. Better support for controlling middleware ordering (#3591). First, I think you meant #730 Second, I think this needs to be a must have, or at least the current behaviour must be *documented*. See discussion on #749 Thanks, Luke -- "Don't mention it. Oh, you didn't." (Marvin the paranoid android) Luke Plant || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django way for adding a cache backend?
Okay, the patch is good to go. Looking forward to seeing it in trunk!
-Lau
On Jun 9, 6:43 pm, Joe Bowman <[EMAIL PROTECTED]> wrote:
> That would be a big help for implementing backends for appengine.
>
> I did notice a project working on an appengine helper for Django
> managed to also accomplish this by creating a cache middleware. So for
> others on appengine currently, using the .96 version of Django
> included within the environment, this is a direction you can look at
> also. I imagine there will be some lag time between a stable release
> of Django and adoption by appengine.
>
> On Jun 9, 11:44 am, Lau Bech Lauritzen <[EMAIL PROTECTED]>
> wrote:
>
> > I created a ticket (including patch) that might be of interest:
>
> > http://code.djangoproject.com/ticket/7398
>
> > On Jun 3, 10:10 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
>
> > > On Tue, Jun 3, 2008 at 2:58 PM, Joe Bowman <[EMAIL PROTECTED]> wrote:
>
> > >
>
> > > > Should I just create it and
> > > > tell people to copy it into the directory with the default cache
> > > > backends? That appears the only way to insert a new one, but I'm so
> > > > new to Django I thought I should ask first and see if there's a
> > > > preferred way.
>
> > > A directory there is currently the only way.
> > > This line in django/core/cache/__init__.py is the culprit:
>
> > > cache_class = getattr(__import__('django.core.cache.backends.%s' %
> > > BACKENDS[scheme], {}, {}, ['']), 'CacheClass')
>
> > > You could, of course, also smash the django.core.cache.cache attribute
> > > with your own, if you wanted to be rude.
>
> > > It certainly seems to me that SESSION_ENGINE (with module pathing) is
> > > a better approach than CACHE_BACKEND (with URI-ish schemes). This
> > > could be overcome by allowing scheme resolution to be registered. The
> > > argument for or against is a bikeshed.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
On Thu, Jun 12, 2008 at 7:06 AM, Forest Bond <[EMAIL PROTECTED]> wrote: > I think that this is a must-have: > > #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff Then you'll be glad to know that it's #3 the list of "Must-have features" in Jacob's email, just a bit below the portion you quoted. -Gul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
On Jun 12, 12:46 pm, Ville Säävuori <[EMAIL PROTECTED]> wrote: > And FWIW, I think the proposed roadmap is brilliant. Not too many > features but still enough to make most of us very happy. Especially if > we can get at least few of the maybes in. Agreed. It is great to see a concrete plan emerging for the coming months. Hopefully, this will reassure the worriers, as well as giving everyone a real target to aim for. The fact that a roadmap exists is the important thing, more than the particular dates that have been chosen. Early September does sound ambitious, but if there is a good level of participation in the sprints, and if the output from those sprints can be reviewed and checked in efficiently enough, it should be achievable. I missed the last sprint and haven't contributed any patches for a while now, but I'm certainly going to try and do my bit to get 1.0 out the door... N. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
> Jacob, honestly, where this date has come from? It can as easily be > August or October. You've outlined a good feature list and seem resolute > to stick to it. But unless all those lieutenants would plan their > features *in work hours*, you just can't know the date. Firstly, as Jacob said, the schedule is just a draft at this point. But I'm very much +1 on locking down spesific dates for any given milestone. It's vital to have firm schedule and dates for making it all happen in a relatively short period of time. As what would those dates exactly be, I couldn't care less. As long as they're not too far in the future, lets jazz on! :) And FWIW, I think the proposed roadmap is brilliant. Not too many features but still enough to make most of us very happy. Especially if we can get at least few of the maybes in. - VS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
Hi, On Jun 11, 10:03 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > * Must-haves: features that, if not completed, are worth delaying the > release. That is, if the work on this list is not completed by a > release date, we'll push the date. I think that this is a must-have: #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff Incidentally, so did Adrian. The text is copied from his post with subject "Django 1.0 features -- the definitive list". http://groups.google.com/group/django-developers/browse_thread/thread/b4c237ad76f9eeca It's in important change and is backwards-incompatible. Thanks, Forest --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
Wow, I'd say this is a pretty good schedule, Jacob. > So we'd like to deal with that situation a bit specially. I've > unfortunately not > had a chance to ask Thejaswi (the student working on comments) or > Jannis (his > mentor) about this, so obviously they'll need to be OK with the idea. I can only answer this preliminarily at the moment due to Thejaswi's absence this week. But I'm confident of his progress and personally think we can meet the schedule. > We encourage people to push newforms-comments pretty hard, > especially during sprints. Good idea. Cheers, Jannis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
Jacob Kaplan-Moss wrote: > Django 1.0 will be released in early September. Ouch... To paraphrase Joel Spolsky "If you have a hand-wavy feature called "1.0 release" and you schedule 3 months for it, you are doomed". Jacob, honestly, where this date has come from? It can as easily be August or October. You've outlined a good feature list and seem resolute to stick to it. But unless all those lieutenants would plan their features *in work hours*, you just can't know the date. I was refraining from saying this because it's not that important after all. However since Simon had (and others will) announce this date all over the internet, we as a community will feel obliged to meet it somehow, e.g. by throwing out really important things that we don't want to. So may be it's not too late to state clearly that we have a plan but it's not a schedule. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Dynamic Fields in Models
I came across the need today to modify PhoneNumberField to allow for International phone numbers. Doing so, it occurred to me, it'd be very useful just to be able to swap out my phone number field with the localized version based on whatever country was selected. Has any thought/real-use happened in regards to doing something along these lines? I could see many use-cases where this could happen, but a lot of it in relation to internalization. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
Hi Jacob, On Thu, Jun 12, 2008 at 5:03 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > 7. Land GeoDjango as ``django.contrib.gis``. Not that I have any right to say anything ... but should this really be a django contrib ? Isn't it more of an external application ? Regards Rajeev J Sebastian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
On Thu, Jun 12, 2008 at 4:03 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > "Maybe" features > > . . . > > 5. Model-level validation (#6845). hi, it always seems quite ugly, that you can create a model with invalid data, and save it. so when you want to validate it's content, you have to hack around and create a form for it, etc... as far as i understand, this change is a backwards-incompatible change, and also touches quite the basic parts of the whole models/forms/validation system, and i thought it's in the plan to have this in 1.0. so i wonder, that if the WSGI-conformance ticket is a must-have, then why this isn't too... perhaps the WSGI-change is smaller... anyway, would be great to have the how-can-we-help data (liutenant/committer/etc) published as soon as possible... gabor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Request for review
Not sure exactly how to phrase this, but James told me to bring these tickets up here to get some feedback on them - such as what exactly needs done to bring them to 'ready for checkin' as myself and others would like to get them in :) I did the basics of making sure the patches were updated, but feedback would be appreciated. Minor, quick performance enhancements: http://code.djangoproject.com/ticket/3460 http://code.djangoproject.com/ticket/3461 http://code.djangoproject.com/ticket/3575 Slightly larger, but also a good enhancement: http://code.djangoproject.com/ticket/4102 The first three are the big ones I'd like to help finish, but 4102 would also be very nice :) -- Collin Grady "We came. We saw. We kicked its ass." -- Bill Murray, _Ghostbusters_ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Is there a django meta model ?
Jean-Christophe Kermagoret said the following: > I need this meta model to generate automatically django code from models. > > If there is no meta model, is there presently some code which would > permit to have code automatically generated from xml (or properly > properties) configuration files ? Usage questions like this belong on the django-users list :) This list is for the development of django itself. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
