The meta API used by admin and model forms should be completely public
and stable. The problem is that some methods of the meta API return
field instances, and the API for the fields (especially for related
fields) isn't public nor stable. You'll need to somehow return field
instance that act like
To clarify, are you referring to a state where there are validation errors and
the form is redisplayed, whereupon your change the value back to the original
value?
Pertaining the problem you mentioned last (displaying the intermediary result):
you are probably better off using the value from th
Another reason you want the two to be separate is that you might allow a field
to be blank in forms but then set the value to some context-specific value (vs
a simple default=x) before saving.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Con
Hi Aymeric,
Pardon my misunderstand of the new functionality, and thanks for the
explanation. The ability to use template libraries outside of installed apps
alone is a great addition. Thanks for your hard work on this.
--
You received this message because you are subscribed to the Google Grou
Hi,
With "support" I meant having a official djangoish way to use sqlalchemy on
django. As I have to use model meta API to add support for any non django
backend to orm my question is, is django meta API fully formalized? If not
how much work is needed to formalize them?(as denial did a lots of wo
Well, one can call the Zen of python, about just exactly that. explicit is
better than implicit.
In this case, explicit becomes a problem for getting used to it, versus
implicit that becomes a strange behavior/bug/wtf when you don't expect it.
I'll rather see a ValueError if this is somethi
Hi Asif,
It depends entirely what you mean by "support".
Django is just Python, so there's absolutely no reason you can't write
a Django site that uses Django for the URLs, views and forms, but
SQLAlchemy for the data access.
Out of the box, you won't be able to use ModelForms or the Admin.
Howe
Hi,
On Wednesday 16 September 2015 03:13:35 Markus Holtermann wrote:
>
> I see the following solutions to bring this PR forward:
>
>1. Configure `django.db.migrations` logger to not send messages to
>console by default and keep log levels to INFO (for "Applied/Unapplied
>migration XY
It would be better if IntegerField, DateField, etc did not have to leave
explicit null=True when blank is True.
In my opinion it might look like:
class Abc(models.Model):
number = models.IntegerField(blank=True) # doesn't need leave explicit
null=True, it's should be default if blank is T
Hi Aron,
I think this feature does not belong in Django; hiding concrete parent fields
sounds like a bad idea which is likely to open a whole can of worms and
violated assumptions.
Since the motivation for the unusual parent-and-child-fields comes from non-
Django uses of the database, I suspec
The problem is with the field clashes. Consider the following
from django.db import models
class TimeStampedModel(models.Model):
created_at = models.DateTimeField(auto_now_add=True)
updated_at = models.DateTimeField(auto_now=True)
class Meta:
abstract = True
class Member(T
Thanks for all of your efforts, Aymeric, I've been following your project
since its inception - I'm FlipperPA on GitHub.
On Sunday, September 13, 2015 at 4:59:34 AM UTC-4, Aymeric Augustin wrote:
>
> Did you mean “pyodbc outperforms pymssql”? Or did you go with pyodbc
> despite lower performance
I also think that this won't need to be in core since a Model Subclass
works. We use this in our Application since we can't hard delete stuff so
we overwritten the Model Field and the manager that all tables contain a
date_deleted field which will be set when calling delete() objects.delete().
And
This mailinglist is about the development of django itself, please write to
django-users.
Cheers,
Florian
On Wednesday, September 16, 2015 at 1:18:37 PM UTC+2, mammar wrote:
>
> Hi All,
>
> I am currently upgrading from django 1.4 to django 1.8, commit_manually is
> removed in django 1.8. Can a
If the user changes a field "username" for example and then saves his
changes form.has_changed() will detect correctly that the username has
changed.
If the user then goes back and changes the username to the old value,
form.has_changed() will return True because the new input differs from
the firs
Hi All,
I am currently upgrading from django 1.4 to django 1.8, commit_manually is
removed in django 1.8. Can anyone suggest the alternative for django 1.8.
Thanks.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itse
What is preventing you from passing the saved changes in via initial?
On Tuesday, September 15, 2015 at 10:23:02 PM UTC+2, Moritz S. wrote:
>
> Hello,
>
> currently you can add data to forms either by passing it into the
> "initial" or the "data" argument of Form. However sometimes I have the
>
Settings.py is definitely not the way to go. As for Meta options: Feel
free, just do it via your own Model subclass, there is no need for this to
be in core imo.
On Wednesday, September 16, 2015 at 7:44:17 AM UTC+2, Aron Podrigal wrote:
>
> Hi,
>
> I'd like to propose a created_at / modified_at
Hi,
How much difficult it will be to add SQLalchemy support to django? what are
the technical difficulties? And which are the ways to add sqlalchemy
support to django?
As SQLalchemy is separated in core and orm will it be wise to use
sqlalchemy core as the backend for django orm? Or through
19 matches
Mail list logo
