Re: Proposal: add new template tag "age"

On 2015-11-11 14:44, Collin Anderson wrote: > Also, doing this from the backend seems like sub-par way to do it. > I would recommend implementing this in javascript, so it can > auto-update over time if you leave the window open. It shouldn't be limited to one or the other: doing it on the back-e

Re: why django 1.9 migrations are essential?

use "manage.py test --keepdb" (available since 1.8)

Re: Proposal: add new template tag "age"

Also, doing this from the backend seems like sub-par way to do it. I would recommend implementing this in javascript, so it can auto-update over time if you leave the window open. On Tuesday, 10 November 2015 14:57:57 UTC-5, jamie wrote: > > On Tue, 2015-11-10 at 18:50 +, Marc Tamlyn wrote:

Re: Support `manage.py shell -c 'run_code_as_django()'`?

I would use this feature. It would be nice for calling a simple function. Though if we didn't add the feature it would be nice to document the text piping option. The one downside of the piping is you get a little bit of garbage in the output, especially when iPython is installed. On Tuesday,

Re: Odd behavior change in 1.8 with {% if %}, RelatedObjectDoesNotExist, and TEMPLATE_STRING_IF_INVALID

On Tuesday 10 November 2015 21:32:36 Tim Graham wrote: > I'd appreciate some opinions on whether or not we should treat this issue > as a regression: https://code.djangoproject.com/ticket/25600 Since this is essentially about the `string_if_invalid` configuration option, whose documentation carri

Re: Form field labels change proposal

I’ve always been annoyed by having to define lower case model field labels and capitalized form field labels. Inconsistencies always creep in. I would like to see this suggestion implemented, if we can provide a decent upgrade story for Django users. -- Aymeric. > On 11 nov. 2015, at 16:59,

Re: why django 1.9 migrations are essential?

Yes, as Tim says, 1.9 actually introduces the ability to mark apps as not having migrations; we specifically chose to keep supporting the migration-less creation format, just as an explicit setting. Note that you can't give an app migrations normally but run the tests without them; for correctness

Re: why django 1.9 migrations are essential?

Hi, have you read the 1.9 release notes? Specifically, "When supplying None as a value in MIGRATION_MODULES , Django will consider the app an app without migrations." If so, maybe we need a better description of

Re: why django 1.9 migrations are essential?

On Wed, Nov 11, 2015, at 16:47, skyjur wrote: > Back before django got migrations with south it was possible to do: > > syncdb --all (create all tables old way)   migrate --fake (mark all > migrations done) Keep in mind that these are not equivalent to running `migrate`. Data migrations would nev

why django 1.9 migrations are essential?

Back before django got migrations with south it was possible to do: syncdb --all (create all tables old way) migrate --fake (mark all migrations done) This flow was very useful in tests as well as when setting up new projects. I'm a bit confused to as to why django took this route and in 1

Re: Form field labels change proposal

I really don't like text-styling functions in Django that are (even indirectly) used in templates. CSS was made for this. The solution Sergei proposed smoothly transitions the admin. However, alot of forms will be affected as well and thus alot of users. The deprecation warning Sergei proposes w

Re: Form field labels change proposal

I think I would start with locally creating a wrapper capfirst that is only called in the referenced line and https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069 (missed that one in the previous post) and possible other ocurrences. Emit a PendingDeprecationW

Re: Form field labels change proposal

How do you envision putting this through a deprecation cycle? On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei Maertens wrote: > > This is a proposal to change how Django generates form field labels from > model fields. Currently, `capfirst` is called on `field.verbose_name` (see > h

Form field labels change proposal

This is a proposal to change how Django generates form field labels from model fields. Currently, `capfirst` is called on `field.verbose_name` (see https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872). This behaviour has been around since pretty much forever a

Re: Feature proposal: selection of views and tables for inspectdb

Hi, I guess it's just about crafting proper SQL for Oracle to do proper introspection and do a PR to be inline with other backends what comes to table/view discovery. On 11.11.2015 14:14, José Tomás Tocino wrote: So... is this going anywhere? El lunes, 9 de noviembre de 2015, 17:55:36 (UTC+

Re: Feature proposal: selection of views and tables for inspectdb

So... is this going anywhere? El lunes, 9 de noviembre de 2015, 17:55:36 (UTC+1), José Tomás Tocino escribió: > > Well maybe extending queries to do that. Wonder is there similiar issues >> with postgresql? >> > > Nope, I've just tried granting SELECT access to a user and he can inspect > the t

Re: Oracle GIS update

Well I fix those algorithm based errors, and do deeper analysis for those yet unknown ones. If I can't figure out why that happens I create ticket for each and mark them expected failures. On 10.11.2015 21:23, Tim Graham wrote: The changes to get it running were merged in September. Absent a p

Re: Django dashboard packages?

On Tuesday, November 10, 2015 at 6:17:00 PM UTC-8, Allison A. wrote: > Hi all, > > I'd like to get an idea of what dashboard packages Django developers > prefer or are using instead of the out-of-the-box admin. > > > 1) "Dashboard" could mean literally hundreds of different things. 2) This is