In Django it is nearly impossible to deal with currency values, intcomma
would make values to currency and it will work on Django 1.6a1 with
Decimals,
but still when I have a ModelForm or Form I can't validate a
intcomma(Decimal()) Value. It will always be incorrect.
Maybe its time now to let
clarify why DecimalField doesn't work for your use case?
>
> I suspect you're encountering problems related to localization, but I'm
> not sure.
>
> Thanks,
>
> --
> Aymeric.
>
>
>
> On 15 juin 2013, at 11:35, Christian Schmitt
> <c.sc...@briefdoma
I would recommand to remove FastCGI.
That's the thing i love with the Python Community. Remove depracted or
obsolete things.
The thing is, there are way more important things to do, than supporting a
'depracted' way to deploy. And it's really not that hard to get mod_wsgi
with a httpd
really not that easy to change your hoster.
Btw. the djangoproject also have a good list which lists some hosters:
https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts
Am Samstag, 20. Juli 2013 13:56:07 UTC+2 schrieb Some Developer:
>
> On 20/07/13 12:32, Christian Schmitt wrote:
>
Am Montag, 9. Dezember 2013 23:37:15 UTC+1 schrieb Carl Meyer:
>
>
> So I would focus more on finding an issue that interests you technically
> or solves a problem you are facing (which will give you motivation to
> work on it). The metadata needed for this query (component, mostly) does
>
I can't change my last post so...
https://code.djangoproject.com/ticket/2284#no1 this ticket looks resolved.
Take a look at :
https://github.com/django/django/blob/master/django/core/management/sql.py#L153
Am Dienstag, 10. Dezember 2013 20:34:54 UTC+1 schrieb Christian Schmitt:
>
>
I didn't found anything in the docs... So... could I stil load a fixture
with a migration? Like here:
http://south.readthedocs.org/en/latest/fixtures.html
Am Freitag, 20. Dezember 2013 17:41:22 UTC+1 schrieb Andrew Godwin:
>
> This will also be true for django.db.migrations; there's no way we
rew
>
>
> On Sat, Dec 21, 2013 at 10:45 PM, Christian Schmitt <
> c.sc...@briefdomain.de > wrote:
>
>> I didn't found anything in the docs... So... could I stil load a fixture
>> with a migration? Like here:
>> http://south.readthedocs.org/en/latest/fixt
Hello,
currently I try to make a TestSuite for a already grown application and it
is horrible to do so.
But thats not why I'm writing here.
Our Application has some data migrations, previously we used South, now we
use the Django 1.7 Migrations with RunPython to do so.
In the Docs there is
eds to be in the database. or i don’t make integrations tests via
the django client. i mean the application is so big that it takes up to 5
seconds to create the test database. which is intact a lot.
but that has nothing to do with the fact, that data migrations are in the docs.
so we should warn
ing flushing? It's not a behaviour
> that can be easily replicated any more, as it relied on the old system of
> one-shot schema and load a single file, but it's also kind of crucial to
> non-transactional tests...
>
> Andrew
>
>
> On Fri, Apr 18, 2014 at 7:56 AM, Christian Schmit
hm, at first i didn't even read the release notes..
But i think we should definitly make a blocker issue in trac.
Currently re-introduce initial_data is the worst thing we could do, since
django 1.9 requires migrations and do deprecate that behavior:
> Deprecated since version 1.7: If an
the only one, so the
1.7 release wouldn’t be that useful for these people as it will be to other
people that don’t use data migrations and/or don’t test their applications.
—
Best Regards
Christian Schmitt
c.schm...@briefdomain.de
Am 22.04.2014 um 03:22 schrieb Russell Keith-Magee <r
This is already merged.
https://docs.djangoproject.com/en/1.6/topics/db/models/#multi-table-inheritance
Am Montag, 12. Mai 2014 11:27:01 UTC+2 schrieb guettli:
>
> Single Table Inheritance is used by ruby-on-rails and SQLAlchemy.
>
> Are there reasons why it is used in django?
>
> I would
Yeah as said that ticket resolved the issue that you can't test data
migrations, so for now on you could use data migrations and test them.
And I think one of the things we should definitly do is a guide for
migrating fixtures to data migrations and work towards that path instead of
fixing
HI,
Currently we developing a Greater Application with many Apps and Models per
App that are referenced through the Apps. We have like 30+ Models and we've
seen an increase of the test suite, too. And what I've seen so far is that
the Post Migrate from the Auth App will take the longest time
Since you've introduced these changes, wouldn't it be suitable to change
Django's commit / review system entirely?
Like introduce gerrit, where very commit / ticket needs to be reviewed by X
people and then it would be marked as merge ready and a "core" or whoever
member could merge that.
There
Is there a way to merge user accounts? Currently my github Account is
c-schmitt, while my Trac user account ist merb.
—
Best Regards
Christian Schmitt
c.schm...@briefdomain.de
Am 24.08.2014 um 21:52 schrieb Ben Finney <ben+pyt...@benfinney.id.au>:
> Aymeric Augustin
> &l
Hello, I read carefully through out the Django Docs and found one comment
really misleading
(https://docs.djangoproject.com/en/1.8/ref/models/fields/#foreignkey):
> Behind the scenes, Django appends "_id" to the field name to create its
database column name. In the above example,
> the
Didn't you missed jsonb from Marc Tamlyn aswell? It's one of the greatest
features for Postgresql
Am Freitag, 17. Juli 2015 19:19:38 UTC+2 schrieb Tim Graham:
>
> Currently we have two items on the roadmap:
> https://code.djangoproject.com/wiki/Version1.9Roadmap
>
> PostgreSQL Full Text Search
20 matches
Mail list logo
