GSOC 2012

Hello everyone, As some of you have already noticed, we've been accepted into GSOC 2012 and we're now starting to discuss ideas with students. The actual application period doesn't open until the 26th March, but we'd encourage you to start discussing applications on this mailing list before

Re: [GSoC 2012] Schema Alteration API proposal

On 19/03/12 11:08, Jonathan French wrote: On 18 March 2012 23:33, Russell Keith-Magee > wrote: > 2. An inspection tool that generates the appropriate python code after >inspecting models and current state of database.

Re: Schema Alteration API proposal

On 19/03/12 20:33, Kushagra Sinha wrote: Andrew's thread[1] also mentions - "backends will always be able to generate SQL for operations, but it won't necessarily be runnable (things like index names can only be resolved at runtime, so you'd get code like "DROP INDEX <> ON users;"." [1]

Re: Improved Error Reporting in Django - GSoC

On 19/03/12 18:12, Sachin Gupta wrote: Hi, My name is Sachin Gupta and I am student of Indian Institute of Technology Roorkee, in my final year of undergraduate course in Computer Science. I have been developing a project entirely based on Django for the last 4 months. Here is the link

Re: Improved Error Reporting in Django - GSoC

On 20/03/12 07:18, Sachin Gupta wrote: Could you guide me what number of error fixes would be good work for GSOC proposal. Also if there are any class of Django errors that are of greater concern (like django.db) There's no clearly defined "number" that would be good - we'll be looking at

Re: Schema Alteration API proposal

On 21/03/12 13:27, Kushagra Sinha wrote: One more thing: The current creation API in django has methods like "sql_create_model" which basically return sql and it is the caller's responsibility to either call cursor.execute on it (syncdb) or output the sql itself (sql). South's (and xtrqt's)

Re: Improved Error Reporting in Django - GSoC

On 20/03/12 20:33, Sachin Gupta wrote: It seems most of the errors on this page https://code.djangoproject.com/wiki/BetterErrorMessages are very old. It states that if the attribute enctype="multitype/form-data" is not sent then the following error comes up TypeError at ... string indices must

[GSOC Announce] Student application period open

Just a quick note to everyone to say that the student application period for GSOC is now open, and closes on Friday, 6th April. As I've mentioned on this list previously, please discuss your applications with us first so we can give you some feedback rather than just submitting them directly

[GSOC Announce] One day remaining for applications

Hi everyone, Just a quick reminder that there's only one day left for GSOC applications - the deadline that they must be filed on the GSOC website by is April 6th, 19:00 UTC (roughly 30 hours from now). Andrew -- You received this message because you are subscribed to the Google Groups

Re: [GSoC 2012] Schema Alteration API proposal

Just thought I'd chime in now I've had a chance to look over the current proposal (I looked at the current one you have in the GSOC system): - When you describe feeding things in from local_fields, are you referring to that being the method by which you're planning to implement things like

Re: [GSoC 2012] Schema Alteration API proposal

On 06/04/12 06:34, j4nu5 wrote: Actually I am not planning to mess with syncdb and other management commands. I will only refactor django.db.backends creation functions like sql_create_model etc. to use the new API. Behaviour and functionality will be the same after refactor, so management

GSOC 2012 Projects

Hi everyone, I'm pleased to announce that Django has accepted two proposals for this year's Google Summer of Code: Customizable serialization, from Piotr Grabowski http://www.google-melange.com/gsoc/project/google/gsoc2012/grap/15001 Security Enhancements, from Rohan Jain

Proposed Field API additions

Hi everyone, As part of my planning for adding schema alteration/migrations into Django proper, I need to make a few changes to Fields to allow for better serialisation of model definitions (pretty much a requirement for any change-detecting migrations system). In particular, I propose: -

Re: Proposed Field API additions

On 07/06/12 20:14, Alex Gaynor wrote: > > > On Thu, Jun 7, 2012 at 12:17 PM, Andrew Godwin <and...@aeracode.org > <mailto:and...@aeracode.org>> wrote: > > > In particular, I propose: > > - Requiring that all fields expose a method w

Re: Proposed Field API additions

On 08/06/12 18:16, Michael Manfre wrote: > > > On Thursday, June 7, 2012 4:16:12 PM UTC-4, Alex Ogier wrote: > > This isn't particularly robust. The SQL string generated by a > particular backend isn't considered part of any API, and might change > formatting or semantics on minor

Re: Proposed Field API additions

On 08/06/12 16:16, Anssi Kääriäinen wrote: > I did a little digging into South code, and I think I now understand > the needs. Basically, when you migrate a model, you might need to read > the database data by using the old model definitions. You can't use > the currently installed model

Re: Proposed Field API additions

On 08/06/12 16:45, Jacob Kaplan-Moss wrote: > Hi Andrew -- > > Generally I'm +1, and I think I see the point pretty clearly. Just a > couple of questions: > > On Thu, Jun 7, 2012 at 7:17 PM, Andrew Godwin <and...@aeracode.org> wrote: >> - Requiring that all fields

Re: Proposed Field API additions

On 08/06/12 17:42, Carl Meyer wrote: > Hi Andrew, > > On Thursday, June 7, 2012 11:17:51 AM UTC-6, Andrew Godwin wrote: > > - Requiring that all fields expose a method which says how to > reconstruct them. > > Essentially, it returns the positional and key

Re: Proposed Field API additions

On 08/06/12 20:01, Anssi Kääriäinen wrote: > On 8 kesä, 19:42, Carl Meyer wrote: >> Yuck. I am not at all convinced that this cure isn't worth than the >> disease. In every case where Django has introduced flattened >> pseudo-namespaces in place of Python's existing namespace

Re: Proposed Field API additions

On 10/06/12 21:54, Anssi Kääriäinen wrote: > I agree the needed_fields.py idea was bad. One part of the idea was > that you would get immediately broken migrations if you remove a > field. Do all the migrations break if you have a broken field > reference, or only when you actually use a migration

Re: Proposed Field API additions

On 11/06/12 10:27, Anssi Kääriäinen wrote: > All of the above sounds good - my main worry was that if you subclass > a field, then it will not get a rule match as the module path prefix > will be different than the parent field's. I don't know if this is an > issue even in South... But if the

Re: QuerySet refactoring

On 13/06/12 17:15, Luke Plant wrote: > I think this is a very necessary piece of work. The problem with that > layer of code is that it is very difficult to really grok and therefore > to review patches. It would take almost as much effort to do a review of > a substantial patch as the patch

Re: Test runner with search

On 14/06/12 11:51, Anssi Kääriäinen wrote: > On 14 kesä, 13:35, Chris Wilson wrote: >> I've made some improvements (in my view) to the DjangoTestSuiteRunner. I >> got tired of having to remember my test class names and of typing so much: >> >> ./manage.py test

Re: auth_permission column lengths

On 19/06/12 15:25, Stephan Jaensch wrote: > Hi Florian, > > Am 19.06.2012 um 16:12 schrieb Florian Apolloner: > >> Django itself can't change that currently since there is no >> support for schema alteration in Core. Once we get that we can >> tackle issues like that and increase to a sensible

Re: auth_permission column lengths

On 19/06/12 16:13, Greg Aker wrote: > Florian: > > I don't think waiting for migrations in the Django core is totally > necessary to fix a bug like this (or others that might be similar). > With proper documentation in the release/upgrade notes, I think it's > completely reasonable to expect

Re: Plans for "forms"

On 21/06/12 11:58, Klaas van Schelven wrote: Hi all, I'm not entirely sure about the forum to ask this question: the motivation is "django-users" like; but since it's about a roadmap / the future I suppose only developers will know the answer. I vaguely remember there being mention of big

Re: Proposal: use SQLAlchemy Core for query generation

On 30/06/12 15:22, Luke Plant wrote: > Hi all, > > A good while back I put forward the idea of using SQLAlchemy Core in > Django [1]. Having had more experience working with SQLAlchemy, I'm > putting that idea forward as a formal proposal, as I mentioned in a more > recent thread here. > >

Re: Proposal: use SQLAlchemy Core for query generation

> I am pretty sure SQLAlchemy-Migrate has fallen out of favor. You should > check Alembic, http://alembic.readthedocs.org/en/latest/. Ah, interesting. Alembic doesn't appear to support fully mutating SQLite databases, which is the really gnarly part of the South code I'd love to outsource.

Re: Django should load custom SQL when testing

On 26/07/12 19:33, Anssi Kääriäinen wrote: On 26 heinä, 19:35, Andrei Antoukh wrote: Having the hooks as a method or function, I find it much more interesting than having them in files. Above that allows logic in these methods, which with flat files is not possible. I also like

Re: GSoC Check-in: Security Enhancements

Thanks for your work during the GSOC, Rohan - don't worry about not achieving everything, it looks like there's still some useful code there! Hopefully we can get some of the code merged, especially centralised tokenisation if it's so near completion, as it looks like a nice bit of cleanup code!

Re: Backporting some Python 3 support features to 1.4.x?

I'm definitely +1 on this - I have a few codebases I want to start converting but also want to keep running on 1.4, and the patch looks sensible to me. There is precedent for this, and even if there wasn't, this is a nice way to get the migration cycle started. Andrew On Thu, Sep 6, 2012 at 3:05

Re: Testing multidb with TEST_MIRROR

That's an incredible speedup - I've had a quick look over the patch, and it looks to be doing all the right things, so I'd definitely be behind merging this in. Have you tried running the test runner over some third-party apps' tests to make sure it works? I suspect South's/migrations' might get

Schema Alteration - Review needed!

Hi all, I have now, I believe, got a working, feature-complete schema alteration branch ready to go. It has full support for PostgreSQL, MySQL, and SQLite, and follows the rough design principles I emailed the list about a while back. It's fully tested, but no documentation yet - I'm not sure

Re: Schema Alteration - Review needed!

> > > Can you put this in a pull-request so I can comment inline? > > I can indeed: https://github.com/django/django/pull/376 Andrew -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Schema Alteration - Review needed!

An update from discussions with Alex and Anssi - I'm going to modify things a little so we don't have a Borg-pattern AppCache (i.e. you can instantiate it multiple times and get different caches), which should solve most of the problems currently caused by app cache state fiddling. Should take a

Re: Schema Alteration - Review needed!

/dbc17d035b255a4da977251fe399f5c80cffeecd https://github.com/andrewgodwin/django/commit/49d1e6b0e20a363cbf9b105e8e6d3fc5fc1cad2f The SQLite test suite all passes after these changes, so this is looking good. Thoughts? Andrew On Tue, Sep 18, 2012 at 4:49 PM, Andrew Godwin <and...@aeracode.org> wrote: >

Schema Alteration update

So, the patch [1] is looking alright, but after some consideration I think it's going to be best to leave this until just after the 1.5 branch has happened and then merge it in as part of the 1.6 cycle. My reasoning is thus: - The whole point of getting something into 1.5 was so I could build

Re: Schema Alteration update

Yeah, I think I mentioned it a couple of times at DjangoCon but perhaps not loudly enough - Jacob and I had a talk at DjangoCon EU where he said he wanted it all in core, and I tend to agree. Preston has had a look at what I'm doing/planning with AppCache and apparently it'll be compatable with

Re: Schema Alteration update

<l.plant...@cantab.net> wrote: > On 28/09/12 08:41, Andrew Godwin wrote: > > Yeah, I think I mentioned it a couple of times at DjangoCon but perhaps > > not loudly enough - Jacob and I had a talk at DjangoCon EU where he said > > he wanted it all in core, and I tend to agr

GSoC 2013 - New and improved!

I'm very pleased to announce that Django is part of Google Summer of Code once again - and that this year, we're widening the scope of the kinds of projects we'll be accepting. In past years, we've only accepted projects working on Django itself, and while this has resulted in some very useful

Re: [GSoC 2013] Improved error reporting

Hi Damian, We don't generally accept GSOC projects that are just a bit grab bag of problems - this is looking a little bit like that. I'd like to see a better breakdown of what kind of time each ticket would take and what your planning schedule would be - in particular, I'd like to make sure you

Re: [GSoC 2013] Composite fields: first draft of the proposal

Hi Michal, This looks like a good starting point for a proposal (not to mention that we don't doubt that you know about the problem area here!) - a few comments: - I'd like a bit more detail on some of your timeline points, in particular what the introspection parts and primary key updates are

GSOC: Deadline soon!

Hi everyone, It's great to see all the GSOC proposals on the list and the feedback being useful, but I feel I should remind you all that the deadline is this Friday, May 3rd, at 7pm UTC (so 11am if you're on the west coast of the US, for example). Melange, the GSOC software, can be a little hard

Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

I feel like the deployment problem is one that cannot be solved in a mere 12 weeks and I'm not sure django-deployer is the right approach to encourage for this - it sits at the wrong level of abstraction and looks pretty fragile, and I'd be hesitant to put any sort of official emphasis on it

Re: Django 1.6 release timeline

I'm happy with this - I doubt schema alteration will be mergeable by the 15th (though I'm trying to get something together for DjangoCon EU) and I want to encourage smaller release cycles. And the new transaction stuff is great, damnit, we should ship that. Andrew On Tue, Apr 30, 2013 at 4:45

Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

ndaries with the new rules. Andrew On Fri, May 3, 2013 at 8:57 AM, Nate Aune <nateja...@gmail.com> wrote: > > On Thursday, May 2, 2013 4:11:35 AM UTC-4, Andrew Godwin wrote: >> >> I feel like the deployment problem is one that cannot be solved in a mere >> 12 w

Re: test discovery

Just want to say that I'm happy with a "fast transition". Is there a possibility we can detect the case where the tests might be broken (how might they be?) and print a helpful error message? Andrew On Thu, May 9, 2013 at 11:51 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > On

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

Of course, the long-term solution for this is probably migrations. The post_syncdb signal already causes me problems - as there's no good definition for it with migrations around (you basically have to send it right at the end for every model you think you touched). However, the patch Donald

Migrations, commands and syncdb

Hi everyone, I'm starting to plan out the commands for the new migrations stuff in Django, and I've hit something of an impasse trying to decide which option to go for. Short background: South modified syncdb to just sync non-migrated apps, and you had to go and run migrate separately to get

Re: Migrations, commands and syncdb

I haven't used South as much as I should have (instead I have painful > manual scripts to do migrations). The biggest pain point about > database schemas for me is easily test database setup. That is, sync > from scratch. I do the following currently: > 1. load schema + a little bit of data from

Re: Digest for django-developers@googlegroups.com - 17 Messages in 3 Topics

5-31 >> 07:39:24) >> >>> From: Andrew Godwin <and...@aeracode.org> >>> Date: May 30 07:03PM +0100 >>> Url: http://groups.google.com/**group/django-developers/msg/** >>> 137ab14f361fd052<http://groups.google.com/group/django-developers/msg/137ab14f

Re: Migrations, commands and syncdb

> > One problem with this is that you have to be careful to write migrations > that will always work from scratch. This is best practice, but I have on > occasion used data migrations that were for specific problems, and may > have depended on specific data in the database. I've also used them for

Re: Migrations, commands and syncdb

grations). > > (PS: +1 to option 3 in principle) > > > On Friday, 31 May 2013 12:44:20 UTC+1, Anssi Kääriäinen wrote: >> >> On 05/31/2013 02:08 PM, Andrew Godwin wrote: >> >> One problem with this is that you have to be careful to write >>> migrations

Merging Schema Alteration branch

Hi everyone, I think it's finally time to look at merging the schema-alteration branch, which has gone slightly beyond its name and encompasses the schema alteration backends and the migration code as well. The branch is working, well tested, moderately documented and has all of the big changes

Re: Merging Schema Alteration branch

I'll take a look at those over the next few days, Florian, it's the most serious bug I've seen for a while! Big issues like that aside, this is never going to be bug-free at merge - I want to bring the merge forward a bit to avoid even more bugs being introduced by master and this branch

Re: Problems with DatabaseCreation, table names, and index names

On 11/03/10 01:05, Russell Keith-Magee wrote: We have an incentive to fix it too -- #12977 points out that Django's own test suite runs foul of this problem. Ah, that's not good. Just documenting the problem isn't really a solution, IMHO. MySQL is the fly in the ointment here, because it

Re: GSoC: Data importation class

I feel the need to wade in here, since this is vaguely my area. On 25/03/10 17:47, subs...@gmail.com wrote: The last bit sounds a bit nebulous. You could optimise it by not including any empty files, or be a bit more specific about what the empty files are meant to represent. :)

Re: Opinions sought on m2m signal ordering

On 27/03/10 17:08, Russell Keith-Magee wrote: There are 5 options I can see. Option 1: Do nothing. #13087 describes a use case we don't want to support, so we ignore it. I think it should be supported; it seems like a reasonable suggestion, and I can see reasons for implementing things

Re: Opinions sought on m2m signal ordering

On 28/03/10 00:01, Russell Keith-Magee wrote: Cache invalidation is a reasonably compelling case for pre-signals; if you invalidate a cache on the post-signal, there is a small window between having modified the m2m and the cache being flushed. In that window, any operation hitting the cache

Proposal: Schema migration/evolution backend

Hi all, As perhaps was inevitable, I'm proposing implementing part of a schema migration backend in Django. I'm not sure if this is a 1.3 thing (it may well be 1.4, perhaps with some implemented in time for 1.3 but not exposed), but it's something I'd like to get started in this release

Re: Proposal: Schema migration/evolution backend

On 28/05/10 13:06, Andrew Godwin wrote: Hi all, As perhaps was inevitable, I'm proposing implementing part of a schema migration backend in Django. I'm not sure if this is a 1.3 thing (it may well be 1.4, perhaps with some implemented in time for 1.3 but not exposed), but it's something I'd

Re: Decision required: PostgreSQL minimum versions

On 09/06/2010 12:59, Russell Keith-Magee wrote: Hi all, While we support PostgreSQL, our documentation doesn't actually specify a minimum supported version. We have a couple of features that are no-ops for versions prior to 8.2 (savepoints and database autocommit), but we don't actually

Imports in the tutorial

Hi all, I noticed today that the tutorial still does imports like "from mysite.polls.models import Poll", and URLs like "(r'^polls/$', 'mysite.polls.views.index')". At least in the places and projects I've worked with, the standard has been not to use the project name as part of the import,

Re: Imports in the tutorial

On 11/06/2010 03:28, Peter Baumgartner wrote: In my experience, almost every project has domain-specific applications that don't get reused. If you have a reusable app, you bundle it separately (like South). I entirely agree, but there's also a lot of domain-specific apps people make

Re: Imports in the tutorial

On 11/06/10 17:00, Peter Baumgartner wrote: > Why do your two sites need to share the same python path? Virtualenv > solves this problem quite gracefully. > They don't have to, but bear in mind that: a) The tutorial is aimed at people new to Django, and often new to Python. Virtualenv isn't

Re: Imports in the tutorial

On 11/06/2010 17:38, Russell Keith-Magee wrote: You're not missing anything specific -- it's really just a matter of time. Good documentation take time to write; doubly so for good tutorials. The issue you raise - that the current tutorial is exclusively "app inside project" has been raised

Re: Imports in the tutorial

On 12/06/2010 01:03, Russell Keith-Magee wrote: What - very very quickly? I don't see the problem :-) Well, that wasn't quite the quality I was going for, but you never know. Problem is there's several things that could go in a part 5 (in addition to all of those there currently),

Re: #6735 -- Class based generic views: call for comment

On 01/10/10 11:17, Luke Plant wrote: Passing things around between '_common' and GET and POST makes a simple view much more complex than it needs to be, especially when you have various local variables that you now have to assign in some way. In the end you will end up just routing it all to the

Re: #6735 -- Class based generic views: call for comment

On 01/10/10 16:25, Brandon Konkle wrote: On Oct 1, 2010, at 10:20 AM, Alex Gaynor wrote: Not really. The big win from a class-based view is not being able to store state, you can do that with local variables, it's being able to override parts of the behavior without needing to rewrite the

Re: #6735 -- Class based generic views: call for comment

On 03/10/10 03:20, Russell Keith-Magee wrote: * Ignore the legitimate occasions where using state is a useful architectural approach. I'd just like to add more noise to the signal and reiterate this - storing state on self (or request) leads to much cleaner, less fragile, more

Re: Smart extends

On 15/10/10 13:41, J. Pablo Martín Cobos wrote: Hi, I'm a Django developer since more or less 3 years. Some time ago I had the need for the extends templatetag to have more funcionality. The funcionality I mean is that a template can extends from "itself". I'm going to try to explain it

Re: #6375 -- Class Based Views: Opinions on commit plan

On 15/10/10 14:52, Ian Lewis wrote: On Fri, Oct 15, 2010 at 2:06 PM, Russell Keith-Magee > wrote: However, this isn't a decision we need to make right now. If we land what we have, we can fiddle with it until the RC comes out;

Re: Feature proposal: escape hatch for colliding template syntax in django templates

On 20/10/10 02:40, Stephen Kelly wrote: Sorry. Sent too early. All thumbs today. Consider these examples: {% verbatim "%} %}" %} (That is, "%} %}" in a verbatim-no-end tag) {% verbatim %} %} %} {% endverbatim %} (That is, " %} %} " wrapped in verbatim tags) The current lexer uses regexps to

Re: prepopulated_fields javascript error since r14123

On 27/10/10 07:01, Simon Meers wrote: Has anyone else found that using prepopulated_fields in admin.ModelAdmin since r14123 produces a javascript error: "d.join is not a function"? I didn't get any errors when I tested the patch before commit - are you having them on the 1.2.X backport, or

Re: prepopulated_fields javascript error since r14123

On 27/10/10 12:15, Simon Meers wrote: > On 27 October 2010 19:40, Andrew Godwin <and...@aeracode.org > <mailto:and...@aeracode.org>> wrote: > > On 27/10/10 07:01, Simon Meers wrote: > > Has anyone else found that using prepopulated_fields in >

Charfields and Admin and None, oh my.

So, I've been trying to trace a bug that's been affecting me as well as someone else I know, to do with ModelForms / the admin and CharFields with null=True, blank=True, and unique=True The old ticket for this was closed as WONTFIX: http://code.djangoproject.com/ticket/9590 However, I'd

Re: Charfields and Admin and None, oh my.

On 11/11/10 01:40, Karen Tracey wrote: > > There is a way, it just requires some admin customization. See: > > http://stackoverflow.com/questions/454436/unique-fields-that-allow-nulls-in-django/1400046#1400046 Right, and you can also register a pre_save hook to fix this, but it's just ugly. > >

Re: RFC: Add a "needinfo" state to triaging

On 13/11/10 16:52, Daniel Moisset wrote: Hi, while working on the sprint today doing triaging we noticed that a lot of tickets were in the "Unreviewed" state because actually there's not enough information to move it to any other state (they can not be neither accepted/DDNd nor closed). In

Re: RFC: Add a "needinfo" state to triaging

On 15/11/10 01:35, Russell Keith-Magee wrote: On Sun, Nov 14, 2010 at 5:22 PM, Andrew Godwin<and...@aeracode.org> wrote: On 13/11/10 16:52, Daniel Moisset wrote: Hi, while working on the sprint today doing triaging we noticed that a lot of tickets were in the "Unrevi

Re: Deprecating ADMIN_MEDIA_PREFIX

On 21/11/10 02:52, Carl Meyer wrote: > Hi all, > > The special-cased handling of contrib.admin static assets in Django > core is a long-time wart. Fortunately, the new static assets standard > introduced by contrib.staticfiles and the STATIC_URL and STATIC_ROOT > settings finally allows us to

Raising more than just 404

So, one of the complaints I've heard from a few people now is the fact that 404 is the only thing one can raise as a HTTP error - there are plenty of others, such as 403 and 405, that could be useful to raise back to the client. This didn't used to be much of a problem with function-based views -

Re: Raising more than just 404

On 03/12/10 22:50, Russell Keith-Magee wrote: This proposal has come up before and has historically been rejected; however, your point about class-based views makes it a lot harder to give the standard responses. Yup; this email came directly from using the new CBVs and hitting this very

Re: Raising more than just 404

On 04/12/10 09:15, Tim Diggins wrote: View& template: look for a handle{{status_code}} variable, falling back to handle_exception. The generic handle_exception in non-DEBUG looks for a specific "{{status_code}}.html" template, but falls back to a (say) "http_exception.html" template. (there

Re: Feedback required: #14799 -- Problem with setting up test databases

My personal preference is for (4). I don't like the addition of a setting, but it's a setting that most users will be able to ignore (since there is a reasonably sensible default), and it is the most explicit and configurable option available. My opinion with the current codebase is for (4),

Re: django.contrib.admin and null=True

On 07/12/10 23:26, schinckel wrote: I haven't been able to find any documentation about this, but would be happy to be pointed in the right direction. When you use null=True in a field, and then use that model in the admin, it will not save NULL to the database, but will instead save an empty

Paginating ListViews in CBV

So, I've been working with the new generic Class Based Views for the last few days, and come across a slight inconsistency in the ListView. If you specify a value for paginate_by, ListView happily returns a "page" object into the context. However, if there is only one page, it decides against

Re: CBV FormView get_form_kwargs() doesn't.... when request.method == "GET"

On 12/01/11 17:54, Daniel Swarbrick wrote: > Most of the time, I use POST for forms, but using GET is useful when > developing a search form, for example. This is especially true if you > want to paginate your results, because you still have all your > original form variables in the query string.

Re: Composite primary keys

On 14/03/11 21:14, Michal Petrucha wrote: Good evening (or whatever it is in everyone's timezone). I'm an undergrad computer science student at the Faculty of Mathematics, Physics and Informatics, Commenius University, Bratislava, Slovakia and I'm willing to participate in this year's GSoc. I'm

Summer of Code 2011: students wanted!

Hello everyone, Django has once again been accepted as one of the participating projects for Google Summer of Code, and so we're now looking for student projects! I've taken over the role of GSoC administrator from Jannis this year; feel free to email me directly (or catch me on IRC) if you have

Re: [GSoC Proposal] Customizable Serialization

On 17/03/11 07:47, Vivek Narayanan wrote: > Hi, > > This is my proposal for the customizable serialization idea: Hi Vivek - sorry about the long reply-wait on this! My initial thoughts are below. > The user can define methods beginning with “meta_” to add metadata > about each field. And

GSoC Student and Mentor Applications Open

Hi everyone, Just a reminder that student and mentor applications for GSoC are now open on the SoC website (middle column, at the bottom): http://www.google-melange.com/gsoc/homepage/google/gsoc2011 Students, you have until 7pm GMT on April 8th to get your submissions in; if you want more

Re: HBase backend support

On 30/03/11 12:58, Rohit wrote: > Hi, > I plan to implement HBase backend support for Django as part of > GSoC 2011. Before I flesh out the idea in detail, I would like to know > if this is useful enough to Django, whether there are alternatives to > using HBase in the first place. Hi Rohit,

GSoC 2011: Only two days left until the student proposal deadline!

As the subject suggests, any potential students who would like to apply to Django for this year's Google Summer Of Code have just over two days left to prepare your proposals and get them submitted. Remember, we'll look much more kindly on proposals that have been submitted to django-developers

GSoC 2011: Less than 24 hours to submit your proposal on Melange

Hello potential GSoC students, There's now less than 24 hours before the deadline closes for GSoC - it closes at 19:00 UTC on April 8th (that's around 20 hours from when this post was sent). If you've got a proposal that isn't in google-melange yet, please register and add it; you're allowed to

Accepted GSoC Projects Announced

Hi everyone, I'm pleased to announce our four accepted GSoC projects for this year: Template Engine Compilation and Runtime Refactoring --- Student: Armin Ronacher Details: http://www.google-melange.com/gsoc/project/google/gsoc2011/mitsuhiko/10001

Re: Proposal: user-friendly API for multi-database support

ab wrote: > For the api to accept a DSN, alias, or connection anywhere would add > similar code in multiple places. I propose that the aliases are mapped > into django.db.connections. For your example, you could use > django.db.connections.archive. I also propose that you can either > define a

Denormalisation, magic, and is it really that useful?

So, hello everyone. I figure this list is the best place to ask this, but please feel free to deride me if not... After all the talk of multiple databases, and non-relational databases (bigtable, couchdb, etc.) that went on at DjangoCon and afterward,I've been thinking about denormali[s/z]ation

Re: Denormalisation, magic, and is it really that useful?

David Cramer wrote: > If you're not doing denormalization in your database, most likely > you're doing something wrong. I really like the approach that is > offered here. > > For me, personally, it would be great if this could accept callables > as well. So you could store the username, like so,

Re: Denormalisation, magic, and is it really that useful?

Yes, Steve, it's true that triggers do have much of the same functionality as this kind of proposal, but as you say, part of the proposal is to make these hopefully work with future non-SQL databases (although, admittedly, that's only a small piece of the puzzle). To be honest, my main drive

Re: Denormalisation, magic, and is it really that useful?

David Cramer wrote: > I would say ignore triggers on the DB level, until they've been > written in the framework. > Yes, this was essentially my point earlier; triggers would be nice to have from a consistency point of view, but it will be easier and quicker to reimplement them in Python, not

  1   2   3   4   5   >