Re: The problem of versioning a large project.

ncationality to your app without touching the settings.py. Just install the Django/GDAPS app per pip, restart the Django server / manage migrate, and it should work. It's not perfect ans still lacks some features, but should solve your problem. Yours, Christian Am 03.04.23 um 16:

Re: dynamically added INSTALLED_APPS

Am 25.02.23 um 17:58 schrieb Silent Coder: Hi Christian and Group, I'm new to Django and still learning the ropes, but I'm curious to know what the use cases for something like this might be. I don't want to use django-developers for this topic more than intended (django dev

Re: dynamically added INSTALLED_APPS

be sure everything is installed as intended, and just order INSTALLED_APPS like I want to. But it's not perfect, I know. So thanks Jörg for your helpful comment. I wasn't quite sure about if I did something stupid. And thanks for your all engaging in Django, it's really a g

Re: dynamically added INSTALLED_APPS

Am 22.02.23 um 22:37 schrieb Jörg Breitbart: Am 21.02.23 um 22:05 schrieb Christian González: My original question was HOW would I implement this in a "good-practice" way, by not violating Django's conventions, and showing a way it could be done clean. I think thats not

Re: dynamically added INSTALLED_APPS

c. Which gets bulky when using 20+ plugins, and maintaining 300 different appliances (for 300 customers) with different (and dynamically changing) plugins. So again, does anything stand against loading plugins' INSTALLED_APPS from a plugin's root module? Is there a better approach

Re: dynamically added INSTALLED_APPS

rom the same vendor. There is no trust problem when installing your own packages. Christian -- Dr. Christian González https://nerdocs.at -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubs

dynamically added INSTALLED_APPS

even creepier to me. Eager to hear your opinion here. -- Dr. Christian González https://nerdocs.at -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop r

PermissionRequiredMixin not importable before apps ready?

ut reduces the same loading time at startup. Which is neglegible IMHO. Please tell me if I'm completely wrong - or if this is worth a bug report/PR. Christian -- Dr. Christian González https://nerdocs.at -- You received this message because you are subscribed to the Google Groups "Djang

Re: django squashmigrations creating incorrect code?

re or less this message would help a lot. Christian -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to d

Re: django squashmigrations creating incorrect code?

AH, sorry. Just saw it: # Functions from the following migrations need manual copying. # Move them and any dependencies into this file, then update the # RunPython operations to refer to the local versions: # medux.core.migrations.0001_initial Am 22.12.22 um 22:12 schrieb Christian González

django squashmigrations creating incorrect code?

n( code=medux.core.migrations.0001_initial.create_admin_user, ), Which is not working, as Python complains: File "/home/christian/Projekte/medux/src/medux/core/migrations/0001_squashed_0003_alter_address_id_alter_addressmapper_id_and_more.py", line 57     code=m

rename internal SetPasswordForm.user into "instance" - or add it

and add a second (optional) parameter named "instance"? The form could then just decide in __init__ if (user|instance) is present, and save the one that is present as self.user. This would ensure that the view could also call it with "instance", both would work. Anythi

ModelForm fields localization

didn't understand why ModelForm does NOT localize fields in the first place per default. You may have a good reason for that. Christian -- Dr. Christian González https://nerdocs.at -- You received this message because you are subscribed to the Google Groups "Django developers (Cont

ModelForm field autofocus

"" autofocus = None def get_form(self, form_class=None):form = super().get_form(form_class) if self.autofocus in form.fields: form.fields[self.autofocus].widget.attrs.update({"autofocus": True}) return form Is this worth including in Django core? Christian -- Dr. Chr

AppConfig subclass-subclass ignored

AppConfigs only as proxy with a pointer to that model... I kindly ask for your opinion here. Christian -- Dr. Christian González https://nerdocs.at -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group

Re: Idea

my part, I would *love* to see HTMX "included" in Django, as it seems to be the perfect couple, if done right. Christian On Wed, Oct 20, 2021 at 6:16 PM 'Adam Johnson' via Django developers (Contributions to Django itself) wrote: Check out htmx as a way to av

Re: Developing an SPA version of Django admin

.) If it was for me, I even would add a neat HTMX integration to Django core. Cheers, Christian Am 15.10.21 um 08:52 schrieb Warren Havemann: Hi everyone, I've been contemplating the development of an SPA version of admin either in Angular, React, Vue or even Flutter... preferably in Angular

optionally show all models in admin per default in DEBUG

.site.register(model)     except admin.sites.AlreadyRegistered:     pass It would help getting started with Django more quickly. -- Dr. Christian González https://nerdocs.at -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to

deconstruct returns 3-tuple?

eturn (self.name, path, [], keywords) This is a 4-tuple, and even the clone() method written after it calls it with name, path, args, kwargs =self.deconstruct() So, is 3.2 documentation here on a <1.9 status? Am I understanding something not correctly? Thanks, Christian -- Dr. Christian

Re: TemplateCommand

Am 28.06.21 um 10:44 schrieb 'Adam Johnson' via Django developers (Contributions to Django itself): > Plus, it's not *that* much code to "take inspiration from" in your own > project, test, and change as you see fit. That's true... ;-) -- Dr. Christian

TemplateCommand

eplace Django's TemplateCommand with it and inherit from it, I could bring it into shape. Please drop me a line. Best regards, Christian -- Dr. Christian González https://nerdocs.at -- You received this message because you are subscribed to the Google Groups "Django developers (Contr

Re: deep frontend integration

ctory. Which is kind of nonsense - BUT, like I asked, could it be a possibility to automate this process, to enable HMR for development? Christian Am 22.01.21 um 08:43 schrieb Christian González: Hello Django community, caution: long post, TL;DR at the bottom. in the past months, I

deep frontend integration

-compressor with a plugin for that. Sorry, no HMR here during development including e.g. Vue or Alpine dynamically comes close to my ideal, but I think a Js compile step is needed. Do you have any thoughts here, hints about how to do that? Mission impossible? Best regards, Christian --

Re: Feature request: Possibility to declare transactions as read only

d I can't create a r/o user for that database. So It would be really cool if I could  tell Django in a DATABASES option that this connection should never be written to. Christian -- You received this message because you are subscribed to the Google Groups "Django developers (Contribut

Re: Proposal: django project name

O, see possible dynamic nature like https://code.djangoproject.com/ticket/31527). So I thought that Django providing a project name (which IS the import path of the main application) would be a good idea. Anyway, my own project will require a PROJECT_NAME variable, because of this template overr

Proposal: django project name

mplicit, so why not a) create a setting (which is created by django-admin createproject along with the other parsed templates) named PROJECT_NAME o DJANGO_PROJECT_NAME or b) (because settings are not used in wsgi.py, manage.py etc.) create it earlier in the process - or does it have to be wri

Re: GDAPS

Oh, sorry, I just saw that this is discussed (andanswered) in the PR. Am 13.01.20 um 23:03 schrieb Christian González: > > Eh, sorry if I misunderstand - but adding a "default = true" line to > an AppConfig is the same as addign default_app_config = > "foo.apps.FooCon

Re: GDAPS

lass is used - none of the two ones. Maybe an error message would be better. default=true should only be valid once! Best regards, Christian Am 12.01.20 um 21:42 schrieb Aymeric Augustin: > Hello, > > I created a PR for this: https://github.com/django/django/pull/12310 > > I'd

Re: GDAPS

e app name only - is ok. I would bet that the vast majority of apps don't have two AppConfigs. And to urge all devs to use the more elaborative AppConfig line in INSTALLED_APPS, just to make such special cases (and THESE are the special cases!) are possible, is wrong IMHO. Let it be

Re: GDAPS

/h in 50 speed limit on the street, when everyone else drives 55. Even Google allows it's self driving cars to drive faster than the limit by 10% in some cases ;-) What I mean is: Why don't you drop that recommendation - when noone is using it - more than one AppConfigs still *are* possi

Re: declarative settings

viour is different when using this module, it doesn't make sense. Such a case should be done in code (module B circumvents the default settings etc.) - but settings merging / hierarchy maybe isn't the best way to go. I also strictly believe in "namespaces are a good thing." S

Re: declarative settings

ve config, installed apps would be defined already - and their paths should be possible to determine by then. So *their* declarative settings could be found and merged as well. Christian -- Dr. Christian González https://nerdocs.at -- You received this message because you are subscribed to the

Re: declarative settings

reasons since I took it over. Yes, this basically means namespacing. Depending on the size of the library, this could be one big bunch of a setting. > I think this pattern solves your first concern Christian. No it doesn't completely. I used this pattern myself in GDAPS, copied from gr

declarative settings

m * load settings.py which allows to override them again (using some special code tricks like dynamic loading, environments etc.) Please tell me what you think about that. Christian -- Dr. Christian González https://nerdocs.at -- You received this message because you are subscribed to the

Re: app_get_config(app_label).path as only way to get an app's path

[app_label] except KeyError: message = "No installed app with label '%s'." % app_label for app_config in self.get_app_configs(): if app_config.name == app_label: message += " Did you mean '%s'?" % app_config.label break This c

app_get_config(app_label).path as only way to get an app's path

label? Is this a bug? Thanks, Christian -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+un

Re: django-admin startproject settings.py has some security holes

SECRET_KEY could be anywhere by default, it doesn't have to be in an executable .py file. But this would mean to change Django's code to read it before or after importing settings.py. +1 for a .gitignore file too. Christian Am 10.10.19 um 22:18 schrieb Ehigie Aito: > Hello Bobby, > I

Logging in management commands

ogging module as default? Thanks, Christian -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr..

Re: docs request: signals documentation warning

glad now ;-) Please, put that into the docs. I saw a talk of the author of django-ddp (a meteor backend served by Django) who spoke a lot about signals, and that they are not nice in terms of performance. This is quite a point. Christian -- You received this message because you are subscr

Re: Oracle DB table prefix missing

This is exactly the ticket my issue is about, des. I'll follow the Konversation there. Thanks Stephen. Greets, Christian Am 17.09.2019 18:19 schrieb "Stephen J. Butler" :Maybe I'm misunderstanding, but tablespace has to do with physical storage of the schema, not how tables

Oracle DB table prefix missing

something completely wrong and it's just my missing configuration? thanks, Christian -- Dr. Christian González https://nerdocs.at -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscr

Re: Redis cache support in core

would be a big benefit IMHO. If I understood all correctly. Greets, Christian Am 05.09.19 um 15:45 schrieb Tom Forbes: > That's not necessarily a blocker, and Memcached is not simple to run > on Windows either - there are no official prebuilt binaries, as far as > I'm

Re: Discussing improvements of django.setup()

y GDAPS plugins system as well, instead of hacking myself into INSTALLED_APPS within settings.py. Just my 2 cents. Christian -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe f

Re: GDAPS

manage.py startproject foo" are NO Appconfigs addressed in INSTALLED_APPS. Nobody does this, right? How "obligate" is this recommendation, when noone uses it? Should this be kept? Thanks, Christian -- You received this message because you are subscribed to the Google Groups

Re: GDAPS

alled then when CorePlugin is 2.0.0. So Core is like any other plugin. And so all plugins depend on Core plugin and could override its defaults. Next problem here is, what if 2 plugins override the default of a third one. The last in the loading row wins then. There are MANY things to

Re: GDAPS

> I've given some thought to this over the years, and what I think we've > somehow missed in settings until now is ... Namespaces! I can second this from my POV, having "evaluated" a few plugin systems now. > Any plugin or app ought be able to declare its own settings and their > defaults. And

Re: GDAPS

to Django (or GDAPS), the loading of apps (GDAPS plugins) could be at least done automatically in a way that dependant apps are loaded after their dependencies. So far... much to do. I hope earth is going to spin slower soon, so a day gets more than 24h. ;-) Christian -- You received this messag

GDAPS

Hi all, sorry, I never managed to introduce myself properly to this mailing list. Christian Gonzalez, more or less hobby programmer, MD as day job. I maybe never will add something substantial to Django core itself, but ATM "scratching my own itch" here: Just wanted to say that I finis

Re: injecting settings

> > It looks like app maintainers really ought to give django-gdaps a > shot. Perhaps Christian, another way would be to contribute gdap > support to the apps you like to use in the ecosystem. Then their > maintainers could benefit from it if they install gdaps and so it can >

Re: injecting settings

} } ) And the app webpack_loader is located *after* this app in INSTALLED apps. Within webpack-loader, the settings dict WEBPACK_LOADER inclusive "foobar" is available. So this is kind of "solved" for me - but - it's a bit of a hack. I'd r

Re: injecting settings

is MY_SETTING is not available globally then? E.g. by apps that are ordered below the app in INSTALLED APPS that declared MY_SETTING? > Here we're talking about something slightly different: formalizing how > an application can declare default values for its own settings — > essentiall

Re: injecting settings

value (Sorry for this maybe shitty code hack) Which then loads everything from installed apps - and later lines would override these "defaults"...? I don't even know if this is possible. Christian -- Dr. Christian González https://nerdocs.at -- You received this message becaus

Re: injecting settings

eally bad workaround, and does not function like I would "phthonically" like it. Christian Am 07.05.19 um 17:02 schrieb J. Pic: > Great idea Christian, actually some frameworks have this kind of > feature, such as CakePHP, in which apps can also inject urls and > middlewares for ex

injecting settings

o load settings from apps too, e.g. with a hook like having .settings.py? which are merged into the main settings? Is this considered as security risk? Thanks, Christian -- Dr. Christian González https://nerdocs.at -- You received this message because you are subscribed to the Google Group

Re: Proposal to format Django using black

.org/git/20190410162409.117264-1-b...@google.com/ So on the long run, no need for git-hyper-blame. Christian -- Dr. Christian González https://nerdocs.at -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" gr

Re: Proposal to format Django using black

Am 14.04.19 um 12:15 schrieb Florian Apolloner: > Hi Christian, > > I think you are making a good argument here. On one hand short-comings > in our tool chain should not block us from making changes. On the > other hand, we do have to live with them -- so having at least some >

Re: Proposal to format Django using black

ying that I'm completely insane, or git already has this feature, or Ii forgot something, I could try and add a git feature request for that. Even if implemented in 2 years, It could be made sure later that git blame worked correctly backwards then. TL;DR: Use black with Django without compromi

Re: Potential suspension of Channels development

integrate channels more deeply into Django, together with frontend 2-way data bindings, push notifications etc., I would really appreciate it and could imagine supporting that using money too. Cheers, Christian Am 22.01.19 um 15:18 schrieb John Obelenus: Chiming in. As a long-time django user (near

Reactive frontend using Django templates?

gin system in the first case, but I think that having a (maybe also pluggable) frontend (like Vue, React, Angular, Polymer etc.) there would be a good idea. Maybe this is something completely different, but maybe you'll find some common parts with your intentions - feel free to share ideas.

Re: Dynamic app loading

t some less > clean. Ok, thanks. I'm already working on extracting my plugin system and making it more generic ;-) I'll post a link when I can release a bit of code. Christian [1] https://docs.djangoproject.com/en/2.1/ref/applications/#for-application-authors -- You received th

Re: Dynamic app loading

:     prl_patterns += pattern.get_patterns This way all plugins can just "implement" predefined Interfaces, supereasy. Greetings from Salzburg, Christian > [1] https://github.com/pretix/pretix > [2] https://packaging.python.org/specifications/entry-points/ > [3] > https://

Dynamic app loading

Hello DjangoDevs, I'm new here to this group, and to be honest, just a "fake" developer. Doing that is not my main job. So please be patient with my maybe BadIdea(tm). Another warning: much text. Hint: there is a TL;DR at the end. I stumbled upon a "missing feature" in Django, which I call "dyna

Re: created_at / modified_at on all database tables

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

Optimizing before applying migrations?

any," which isn't feasible in shipping products.). It seems that the same optimization work could be done at application time though, couldn't it? Are there already plans to add an optimizer for the full migration? What are the big issues blocking it? Thanks, Christian -

Re: Pre-DEP: community support of unmaintained versions of Django

fice as opposed to needing a build environment and source to install it. It's starting to sound like the best bet for us is to move away from pip/easy_install for end-user consumption of the software and onto more of a dedicated installer that can manage dependencies more explicitly, maybe t

Re: Pre-DEP: community support of unmaintained versions of Django

On Wed, Aug 19, 2015 at 4:43 PM, Markus Holtermann wrote: > Hey Christian, > > On Wed, Aug 19, 2015 at 02:41:49PM -0700, Christian Hammond wrote: > >> Regarding the version number, from what I've read, there's still a >> reported >> compatibility issue

Re: Pre-DEP: community support of unmaintained versions of Django

s, though, we sign all the builds and include checksums in both the links and in dedicated .sha256sum files. Not the best solution, but it's something at least :/ Christian -- Christian Hammond - chip...@chipx86.com Review Board - https://www.reviewboard.org Beanbag, Inc. - https://www.bea

Re: Pre-DEP: community support of unmaintained versions of Django

security fixes to a branch, ensured the test suite passes with flying colors, and have added a README detailing everything you've requested. This is all up at https://github.com/beanbaginc/django. Let me know if there's anything you'd like changed. Thanks, Christian On Fri

Re: Support for UNLOGGED tables in PostgreSQL

I mean I made the proposal, but one drawback will be when linking to Postgresql Docs, what if they change the links? I mean that's barely happend in the past, however the " http://www.postgresql.org/docs/current/static/non-durability.html"; is fairly new. (9.x). So we need to track every major upgr

Re: Major features for 1.9

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 <

Re: Support for UNLOGGED tables in PostgreSQL

Wouldn't it be enough to just have link to the correct PostgreSQL site: http://www.postgresql.org/docs/current/static/non-durability.html And then some text with "if you want to run your tests on postgresql please see the docs around non durable postgres" 2015-07-13 18:46 GMT+02:00 Federico Capoan

Misleading Documentation on Model Field Reference

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 database

Re: Pre-DEP: community support of unmaintained versions of Django

security issues, etc. Thanks! Christian On Friday, March 20, 2015 at 10:02:40 AM UTC-7, Carl Meyer wrote: > > Hi James, > > Thanks for taking the time to write this up carefully, research the > history, etc. I think some form of extended community-based support > could work, but I

Re: ANN: Django website redesign launched

Somehow I hate it. The website is the worst website I've seen since a long time. The contrast is really aweful. The issue Tracker got unusable due to the colors that aren't focused on readability. Overall it looks like a mess, just to have a new design. Doesn't look like a designer or a graphic g

Re: Configurable safety options for high performance Django systems

> > Nope. a large OFFSET of N will read through N rows, regardless index > coverage. see http://www.postgresql.org/docs/9.1/static/queries-limit.html > That's simple not true. If you define a Order By with a well indexes query, the database will only do a bitmap scan. This wiki isn't well explaine

Re: Configurable safety options for high performance Django systems

A sequence scan will only be made, if you query non indexed values. So if you add a simple ORDER BY you will make a index scan, which is very fast. The problem relies more on the database than on the ORM. As already said. If you need to deal with that much queries you need to log your SQL statement

Re: Configurable safety options for high performance Django systems

Sorry, but I don't think this is suitable. If somebody has 100M rows per Table then, he should prolly think about sharding/replication anyway. So the ORM would still suffer anyway. Currently my company has a few tables with a high count as well but since we never used the django-admin and managed t

Re: Requiring GitHub login for actions on Trac

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 : > Aymeric Augustin > > writes: > >> Contr

Re: Requiring GitHub login for actions on Trac

I'm a little bit concerned about that. First I'm using a different user on Trac than on Github, so everything I wrote so far will getting lost (not that bad problem for me), but I think there are many users who are in the same situation. The next thing is vendor lock-in. What will happen if Github

Re: Updating the organization of the Django Project

> Christian, have you seen the patch review checklist I put together? Yep and I will definitely do some more work in the future. Everything i write now is my personal opinion. first of all trac has some of the weakest Query Filters. (thats my personal opinion) the next thing is that changing

Re: Updating the organization of the Django Project

locker for a lot of things on my side. i think the ux is somewhat bad, but thats just an own perspective. 2014-08-01 21:49 GMT+02:00 Carl Meyer : > Hi Christian, > > On 08/01/2014 01:37 PM, Schmitt, Christian wrote: > [snip] > > i mean maybe we should really look at a re

Re: Updating the organization of the Django Project

; aymeric.augus...@polytechnique.org>: > On 1 août 2014, at 18:31, Christian Schmitt > wrote: > > Since you've introduced these changes, wouldn't it be suitable to change > Django's commit / review system entirely? > > > “Hey, you climbed this hill just

Re: Updating the organization of the Django Project

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

Re: 1.7 release status (RC2 coming soon)

Currently I don't think there is a need for a second RC yet. As already said you could easily install via Git (maybe we should add that to the docs) Like: "If you want to test the latest development version of Django just use pip and git to install it: pip install git+https://github.com/django/

Re: [1.7-RC] Using coverage with migrated app slow down test-suite execution by 6 times.

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 to

Re: Loading fixtures once for each TestCase to improve running time

encourage people to not use fixtures and build their test data > within the scope of the test or the TestCase. > > Regards, > Michael manfre > > > On Thu, Jun 12, 2014 at 9:17 AM, Schmitt, Christian < > c.sc...@briefdomain.de > wrote: > >> Just a quick questi

Re: Loading fixtures once for each TestCase to improve running time

Just a quick question regarding to these posts / tickets. In the last few weeks we fixed: https://code.djangoproject.com/ticket/22487 So I think that we now don't need to rely on fixtures and should just tell the people to use that behavior in the first place. I mean I'm not a Django core develop

Re: Why not Single Table Inheritance?

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 lov

Re: Data Migrations and Testing

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 : > defer

Re: Data Migrations and Testing

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 applicati

Re: Data Migrations and Testing

we should look into deprecating 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 > > &g

Re: Data Migrations and Testing

Currently my way to fix it will be to rewrite everything and don’t really on data that needs 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

Data Migrations and Testing

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 als

Re: index_together should also have the same convinience as unique_together

cleaned up and updated. — Best Regards Christian Schmitt c.schm...@briefdomain.de Am 01.03.2014 um 12:46 schrieb Florian Apolloner : > Hi, > > there is no need to mail django-developers when you open a PR -- we do > monitor the relevant lists. > > Cheers, > Florian > &

Re: [GSoC] Switching to Jinja2 proposal

I'm not a django-developer, but I'm creating a lot of applications with Django and I would never want to switch to Jinja2. Why? The first thing is that Django Templates are simple to understand, they are not formed as a new DSL or a Programmable way of a Template language. Their Syntax is clear a

Re: South data-migration and custom save() method

tions. > > Andrew > > > 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.readt

Re: South data-migration and custom save() method

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 ca

Re: Trac and getting started contributing (was: 1.7 Release Schedule)

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: >

Re: Trac and getting started contributing (was: 1.7 Release Schedule)

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 > ten

Re: 1.7 Release Schedule

I also hoped that the release date will be way before the 15th of may. Also just a question.. I currently looking forward to maybe contribute something back to django. But I always struggle with trac it looks so extremly messy. I mean i try to query some unresolved, accepted queries: https://code

  1   2   >