Re: Major features for 1.9

[Christian Schmitt]

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  
> (Marc Tamlyn)
> Custom indexes  (Marc Tamlyn)
>
> Hopefully we can add Marten's URLs GSoC project to this list.
>
> I removed composite fields as Thomas indicated he doesn't plan to continue 
> work on it. 
>
> We have about two months until the alpha feature freeze (planned for 
> September 21). If anyone is planning any ambitious patches, let us know!
>

-- 
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...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/db629ea7-cdb0-4951-b52c-98dd1cf24485%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Misleading Documentation on Model Field Reference

[Christian Schmitt]

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 table for the Car model will have a manufacturer_id column. 
(You can change this explicitly by specifying db_column 

) 
> However, your code should never have to deal with the database column 
name, unless you write custom SQL. 
> You’ll always deal with the field names of your model object.

Currently nothing in the first two paragraphs is obviously wrong, however 
the second part is. Since when dealing with SQL YOU SHOULD now your column 
name.
db_column Name could save you a really expensive join when you don't need 
to access more data.
I mean the best example obviously comes with Username's. Here is an example:

from django.db import models

class Tweet(models.Model):
message = models.TextField()
   username = models.ForeignKey('auth.User', db_column='username')

When you now need to represent tweets to a user you could easily write that:
Tweet.objects.all()
You now have all the Tweets and the Usernames.

However if you want to present the Tweet and the Username while using the 
following:

from django.db import models

class Tweet(models.Model):
message = models.TextField()
   user = models.ForeignKey('auth.User')

You would obviously need a join to get the username.

So that part is really misleading and It would be great to have more 
documentation about db_column since it could save some time at the database 
level, especially when dealing with UNIQUE strings etc.

-- 
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...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9f774f9e-b008-471a-a17f-8e3398c751c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Requiring GitHub login for actions on Trac

[Christian Schmitt]

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
> <aymeric.augus...@polytechnique.org>
> writes:
> 
>> Contributors who refuse GitHub's ToS can participate on Trac again.
> 
> For working to fix this, and for acknowledging these people are
> contributors: Thank you!
> 
> -- 
> \   “Truth is stranger than fiction, but it is because fiction is |
>  `\ obliged to stick to possibilities, truth isn't.” —Mark Twain, |
> _o__)  _Following the Equator_ |
> Ben Finney
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/8538clzmv8.fsf%40benfinney.id.au.
> For more options, visit https://groups.google.com/d/optout.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Updating the organization of the Django Project

[Christian Schmitt]

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 are a lot of projects which uses this kind of workflow.

Also there are like 120 Pull Requests which are over an year old 
sometimes.Which scary's off a lot of people. We should do something against 
it to have a "cleaner" queue.



Am Freitag, 1. August 2014 15:34:48 UTC+2 schrieb Aymeric Augustin:
>
> Hello, 
>
> Since the proposal was accepted with sixteen +1, I committed it: 
> https://github.com/django/django/commit/8c2b405ba8343e68bc32ac2c860be0c6cfd7d631.
>  
> The next step is to elect the first technical board, as soon as 1.7 final 
> is released. 
>
> As Tim noticed, team.txt and roles.txt are unrelated to Django versions. I 
> suggest to keep master up to date and leave each version whatever was there 
> when its branch was forked. I’d rather not make the wiki an authoritative 
> source of information. If someone wants to build a better solution, that’s 
> cool. 
>
> I would like to thank all those who took the time to comment on the 
> proposal as well as the entire core team for accepting to relinquish a few 
> of its individual prerogatives. 
>
> -- 
> Aymeric. 
>
>
>
> On 23 juil. 2014, at 15:29, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
>
> > Hello, 
> > 
> > I’ve been working on updating our organization: 
> https://github.com/django/django/pull/2947 
> > 
> > This proposal attempts to address several issues with our current 
> organization. There’s no short version and any simplistic interpretation 
> will be wrong. Here are the main factors at play. 
> > 
> > 1) In theory, the core team is the group of committers, each of whom has 
> been judged capable of making code design decisions. (Astute readers will 
> have noticed that it isn’t true in practice.) This restrictive approach to 
> staffing makes it hard to cover all of our HR needs. Specifically: 
> > a) It creates a chasm between non-core and core contributors, 
> which has perverse side effects and creates tons of frustration. 
> > b) It drives away would-be contributors whose help wouldn’t 
> involve committing code to the main Django repository. 
> > c) Even if such contributors are found, it’s hard to convince 
> the core team to bring them on board. 
> > 
> > 2) Since the BDFLs have stepped down, there’s no obvious way to 
> counteract honest mistakes made by core developers. This is making the core 
> team uncomfortable at times. While BDFLs hardly ever had to intervene, 
> their mere existence played a role. We need to recreate that role in a more 
> democratic fashion. 
> > 
> > 3) We’re good at burning out our most prolific contributors. Since we 
> lack structure, it’s too easy to become responsible for everything, until 
> you can’t handle it anymore and throw the towel. We must classify roles, 
> write down who takes what role, fill the gaps with new volunteers, and 
> remove pressure around stepping down. 
> > 
> > 4) As we have grown, having no explicit organization within the core 
> team makes it complicated for newcomers to figure who does what and how 
> they fit in the picture. It doesn’t erase the power structure. It merely 
> hides it. 
> > 
> > My proposal builds upon years of discussions at DjangoCons. It has gone 
> through many rounds of feedback inside the core team already. It’s an 
> evolution, not a revolution. It takes into account the growth of the 
> project, acknowledges and formalizes some things that we’re already doing, 
> and introduces just enough formal organization to make everyone 
> comfortable. 
> > 
> > It doesn’t encompass everything we could do to improve our organization. 
> In particular I expect some follow up work on how we manage roles in order 
> to avoid burnout. 
> > 
> > I would like to ask the core team for a formal vote on this pull 
> request, according to our guidelines. [1] Please vote by the end of July in 
> UTC (2014-08-01T00:00:00Z). 
> > 
> > Obviously, I’m voting +1. 
> > 
> > Thank you, 
> > 
> > -- 
> > Aymeric. 
> > 
> > 
> > [1] 
> https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-features/#how-we-make-decisions
>  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6b02f379-7a95-4d87-8f68-9d33d250e27e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Christian Schmitt]

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 run. So 
maybe there is even a greater slowdown when used with coverage.


Am Dienstag, 8. Juli 2014 12:55:24 UTC+2 schrieb Stan:
>
> Hi devs,
>
>
> Since Django-1.7-RC, apps containing models that inherit from "migrated" 
> must be "migrated". 
> My project (*fab4*) contains 7 apps and only 1 (*parametrage*) has been 
> migrated (as explained in the doc 
> )
>  
> because it inherits from *User* and *Site*.
> Using the flag -v 2 shows that applying that single migration file during 
> the tests take ~30s on my 2007-not-that-old dev machine and may explains 
> the gap in processing time between 1.6 and 1.7-RC.
>
> I am not sure that migrations it is the root of the problem but running my 
> test suite now takes ~2220s instead of ~340s if it is launched inside 
> Python *Coverage*. 
>
> *python manage.py test fab4* take 344s.
>
> With coverage it take 2 200s:
>
> *coverage run --source='.' 
> --omit='**/migrations/*,**/tests.py,**/tests/*,./fab4/local_settings.py,./setup.py,./manage.py,**/urls.py,fab4/wsgi.py'
>  
> manage.py test fab4*
>
> Where it used to take ~350s with the 1.7Beta (and parametrage not 
> migrated).
>
>
> Everything is run into a virtualenv with Python-2.7, MySQL (InnoDB).
> anyone noticed something similar since using migrated apps or the RC?
>
>
> Thanks.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1be89898-b7e0-433b-8693-5d9bc1746d5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Christian Schmitt]

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 behavior that are getting deprecated anyway.
Also there is still work to do, since this conversation also focues on the 
data migrations part. As already said, their behavior is nearly the same 
and maybe we could do something to have data migrations be super fast, so 
that people have another reason to stay away or migrate away from fixtures. 


Am Donnerstag, 12. Juni 2014 15:35:28 UTC+2 schrieb Michael Manfre:
>
> That ticket seems to address issues with initial_data and not necessarily 
> deal with fixtures that are loaded for a specific TestCase. I do agree that 
> we should 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 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 developer, but since we fix our code for 
>> Django 1.7 our test suite runs faster since we dropped them out.
>>
>> Also we wrote somethings in the docs about that:
>> Deprecated since version 1.7: If an application uses migrations, there 
>> is no automatic loading of fixtures. Since migrations will be required for 
>> applications in Django 2.0, this behavior is considered deprecated. If you 
>> want to load initial data for an app, consider doing it in a data 
>> migration 
>> 
>> .
>>
>> The question about that is, what happens if you don't use migrations. 
>> Will fixtures still be loaded in Django 2.0 and upwards or not.
>> If they will be loaded, we should fix this, but if not we should maybe 
>> clear that things up that the people SHOULD migrate away from fixtures to 
>> migrations.
>>
>> Quick Note: I think, currently the data migrations still uses the old 
>> technique, by serializing / deserialize on every test case, so maybe we 
>> should expand that logic somehow instead of putting work onto fixtures.
>>
>>
>>
>>
>> 2014-06-11 16:37 GMT+02:00 Josh Smeaton > >:
>>
>> manfre was nice enough to test this patch out on mssql for me. The subset 
>>> of tests that use fixtures went from 385 seconds to 158 seconds (+2 
>>> failures). The improvement seems to be stable across backends, but isn't 
>>> very significant when considering the entire test suite.
>>>
>>> I'm going to abandon this patch and ticket myself - mainly due to the 
>>> sqlite threading issues. If someone else would like to run with it, I'll be 
>>> happy to share any information I have.
>>>
>>> - Josh
>>>
>>>
>>> On Wednesday, 11 June 2014 09:34:14 UTC+10, Josh Smeaton wrote:

 I used the patch in the above ticket as a base, and implemented fixture 
 loading in the setUpClass classmethod rather than the setUp method. I 
 found 
 that it improved the total running time of the entire test suite by about 
 10%, but it improved TestCases that use fixtures by a factor of 3.

 https://github.com/jarshwah/django/tree/testcase-optimization

 I'm unable to test this patch on Oracle or mssql though, which are 
 known to be a lot slower than most of the other backends (for the test 
 suite). The list of test modules that use fixtures are:

 admin_changelist admin_custom_urls admin_docs admin_inlines admin_views 
 admin_widgets aggregation aggregation_regress contenttypes_tests fixtures 
 fixtures_model_package generic_inline_admin known_related_objects 
 m2m_through_regress multiple_database proxy_models raw_query servers 
 syndication_tests test_client test_client_regress test_utils timezones


 If someone is able to test Oracle or mssql with that set of test modules 
 and report back the difference in time taken between master and the above 
 branch, that'd be extremely useful information.


 As for profiling the entire test suite:


  vagrant@djangocore:~$ PYTHONPATH=/django 
 /home/vagrant/.virtualenvs/py2.7/bin/python 
 -m cProfile -s cumulative /django/tests/runtests.py

 This shows that for psql, mysql (inno), and sqlite, the majority of 
 (cumulative) time is spent inside the request/response phases of the test 
 client, reversing urls, and rendering templates. I don't think the choice 
 of backend would massively influence these tests (unless transactions 
 themselves are especially 

Re: Why not Single Table Inheritance?

[Christian Schmitt]

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 love to see a polymorphic inheritance solution in django. 
>
> I know that there are third party apps which provide this, but 
> something like this should be in the core. 
>
> There was some discussion about this [1]. One reason against it was, 
> that supporting not-null is not available. But a db constraint which 
> checks the type and data column could solve this. 
>
> What do you think? 
>
>Thomas Güttler 
>
> [1] 
> https://code.djangoproject.com/wiki/ModelInheritance#a1.ModelingparentrelationsinSQL
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7df9c4cb-daa2-41be-b08f-804dbba348e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Data Migrations and Testing

[Christian Schmitt]

Hm, I’m not a core developer, but i wouldn’t prefer the documentation that 
explains the edge cases.

As Russel Keith-Magee already said that Django is a tool that ensures quality.
We should definitly make a Ticket and try to clear that thing up before the 1.7 
release. I mean this is not a new feature since Django 1.7 should already 
support Data Migrations even in TestCases.

Also I don’t think that people will read every part of the documentation. I 
don’t know how many people will use Migrations and especially Data Migrations 
and rely on Django’s TestCases but i don’t think that i’m 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 <russ...@keith-magee.com>:

> deferred



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Data Migrations and Testing

[Christian Schmitt]

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 application uses migrations, there is 
no automatic loading of fixtures. Since migrations will be required for 
applications in Django 1.9, this behavior is 
> considered deprecated. If you want to load initial data for an app, 
consider doing it in a migration.

Currently I think that the third solution could be the best, in my case we 
have like a dataset of 50 or more entries as initial data, which could 
easily be mocked and/or dumped and reloaded. It won't take that much time. 
And as you already said for bigger applications fixtures didn't work, too.
But I don't think it will make it in Django 1.7 and since data migrations 
are unusable if you rely on testing and initial_data this wouldn't be too 
good.

> At this time I haven't touched the new migrations system for django. But 
now, reading the releases notes and this thread... 
> I don't understand how data migrations can replace initial_data, are two 
things completely different and they have completely different scope. I'm 
slightly confusing.

Data Migrations are the same thing than initial_data i mean they can be 
used to load a data set and drop that dataset, thats way more flexible. But 
currently Django's TestSuite isn't prepared for Data Migrations. Thats 
infact a problem. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6c14d75b-6720-4c97-b697-93adb759f134%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Data Migrations and Testing

[Christian Schmitt]

The first solution is definitly the worst, if you make integration tests 
you already have a "long running" test suite (especially with over 20-30 
models).
initial_data fixtures having a problem, if you change your database the 
initial_data will change over time, which is somehow bad to integrate.
Also dumping the content to a file could be really really slow. As said the 
initial db creation of our tests already takes like 5 seconds.

btw. currently a database (that supports transactions) that has initial 
data at the migration level won't contain your initial data even with 
TestCase. So maybe this is a bug or PostgreSQL won't have transactions??!? 
I even tried the AUTOCOMMIT False / True, w/e still no effect. My Initial 
Data is lost. 
So to make your fourth solution work, we would need to fix it. That initial 
Data stays in the database if running TestCase instead of 
TransactionTestCase.

And yes, the fourth one is somehow dump, but it would definitely tell me 
the things that i heard in many talks. "The Database is hot lava". I would 
change my test suite completely to only have function tests and "real" 
unittests without any database dependency..

The last thing would be great, but i don't think its something that could 
make it into 1.7, so we would rely on your forth solution. Tell people that 
data migrations shouldn't be used if you have a database without 
transactions if you want to keep your test suite up and running (and fix 
the problem that datamigrations on databases with transactions won't get 
lost in _pre_setup())


Am Freitag, 18. April 2014 18:41:06 UTC+2 schrieb Andrew Godwin:
>
> Ah yes, flushing, I forgot we did that for lesser DBs.
>
> I can think of several solutions:
>  - Run the entire migration set every time you flush the database. This 
> is, obviously, not practicable.
>  - Re-introduce initial_data fixtures; I'd rather not, as these require 
> constant upkeep and interact badly with migrations.
>  - Dump the content of all apps at the start of tests into a file and 
> restore from that after flushes. This is a bit hacky and might use a lot of 
> disk space, but would get the intended effect.
>  - Say that you can't use datamigrations if you have a database without 
> transactions (not ideal)
>
> Nothing here is really a great solution, alas. The fourth one is the 
> easiest solution - tell people to use factories in tests or fixtures if 
> they want that stuff - but slightly undermines the idea of loading initial 
> data in a migration (which is the better way of doing it).
>
> Perhaps 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
>
>
> On Fri, Apr 18, 2014 at 7:56 AM, Christian Schmitt 
> <c.sc...@briefdomain.de
> > wrote:
>
>> The case is really simple and i think its definitely that would block the 
>> release.
>>
>> First off, I have a model:
>>
>> from django.db import models
>>
>> # Create your models here.
>> class SimpleModel(models.Model):
>> name = models.CharField(max_length=10)
>>
>> Then I will make some migrations:
>> # encoding: utf8
>> from django.db import models, migrations
>>
>>
>> class Migration(migrations.Migration):
>>
>> dependencies = [
>> ]
>>
>> operations = [
>> migrations.CreateModel(
>> name='SimpleModel',
>> fields=[
>> ('id', models.AutoField(serialize=False, 
>> primary_key=True, verbose_name='ID', auto_created=True)),
>> ('name', models.CharField(max_length=10)),
>> ],
>> options={
>> },
>> bases=(models.Model,),
>> ),
>> ]
>> Now the second one that loads data:
>> # encoding: utf8
>>  from django.db import models, migrations
>>
>>
>> def add_data(apps, schema_editor):
>> SimpleModel = apps.get_model("new_app", "SimpleModel")
>>  SimpleModel.objects.create(name="simple")
>>
>> class Migration(migrations.Migration):
>>
>> dependencies = [
>> ('new_app', '0001_initial'),
>> ]
>>
>> operations = [
>> migrations.RunPython(add_data),
>> ]
>>
>> Now I have a view that makes a get query:
>> from django.http import HttpResponse
>> from .models import SimpleModel
>>
>> # Create your views here.
>> def simple(request):
>> simple = SimpleModel.objects.get

Re: Data Migrations and Testing

[Christian Schmitt]

 views where NOBODY could delete these get() queries, so we 
rely on them and they will fail, if we try to make tests.
Too bad our application is now too big to think about application design, i 
also think its „impractical“ but i don’t think i’m the only one. the same 
problems have/had fixtures as well.

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 has nothing to do with the fact, that data migrations are in the docs. 
so we should warn that this will make it harder to test your application if you 
rely on that data. especially when you query with get().



—
Best Regards

Christian Schmitt
c.schm...@briefdomain.de




Am 17.04.2014 um 22:42 schrieb Andrew Godwin <and...@aeracode.org>:

> Hi Christian,
> 
> Can you explain your situation more, and perhaps give us some example files 
> or console output? When you run tests they should run through all the 
> migrations first, so any initial data should get loaded in before tests begin.
> 
> Andrew
> 
> 
> On Thu, Apr 17, 2014 at 1:16 PM, Christian Schmitt <c.schm...@briefdomain.de> 
> wrote:
> 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 also a Article how to do it: 
> https://docs.djangoproject.com/en/dev/topics/migrations/#data-migrations
> Currently If you load initial data with a RunPython command that your App 
> Depends on (there are some cases, not many, but some) you will fail hard.
> Your Unittests starting to fail. And that is not good, so i think we should 
> either change something on the Test Suites or we should make it clear that 
> Data Migrations for initial data is a bad idea or maybe warn about the 
> drawbacks with Test Cases.
> I'm really new to testing and I really needed to figure out whats going on 
> first until I realized that this behavior comes from the TestSuite.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/768969da-8f75-4402-80a5-c30c27c74997%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAFwN1uqasqm17EKHg1PrL5HbJaE3W2hVn%3DBe3wd45yxKRDR04w%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Data Migrations and Testing

[Christian Schmitt]

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 also a Article how to do 
it: https://docs.djangoproject.com/en/dev/topics/migrations/#data-migrations
Currently If you load initial data with a RunPython command that your App 
Depends on (there are some cases, not many, but some) you will fail hard.
Your Unittests starting to fail. And that is not good, so i think we should 
either change something on the Test Suites or we should make it clear that 
Data Migrations for initial data is a bad idea or maybe warn about the 
drawbacks with Test Cases.
I'm really new to testing and I really needed to figure out whats going on 
first until I realized that this behavior comes from the TestSuite.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/768969da-8f75-4402-80a5-c30c27c74997%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Christian Schmitt]

That's what i do in south, sometimes.

But sometimes you have a bigger table with initial data, like a table with 
predefined prices. and it wouldn't be that cool to instantiate 20.000 or 
more prices manually.

Am Sonntag, 22. Dezember 2013 12:06:02 UTC+1 schrieb Andrew Godwin:
>
> It won't load initial_data fixtures - those are being deprecated for 
> migrated apps - but you could still call loaddata with a custom one, I 
> guess. I'd personally recommend moving away from fixtures and just 
> instantiating objects directly using the ORM inside data migrations.
>
> 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.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 can 
>>> serialise save methods as part of the model for later use in migrations. If 
>>> you want to use complex save logic in migrations, you'll have to copy it 
>>> into the migration file (which also means the migration will keep working 
>>> as originally written if you later change what the save method does).
>>>
>>> Andrew
>>>
>>>
>>> On Fri, Dec 20, 2013 at 4:15 PM, Val Neekman <v...@neekman.com> wrote:
>>>
>>>> South (latest) has a limitation where it ignores a custom save() method 
>>>> in the model class.
>>>>  
>>>> I am wondering if that is going to be true for the new South in the 
>>>> core in Django 1.7?
>>>>
>>>> Thanks,
>>>>
>>>> Val
>>>>
>>>>  -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Django developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to django-develop...@googlegroups.com.
>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>>
>>>> Visit this group at http://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>> msgid/django-developers/CADy_H8ERxnyrzf5UGOTPt1%
>>>> 3DUmj46himOBJ3w%2BBrxL49u_E3qyA%40mail.gmail.com.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>
>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/c219ae48-16fe-4149-91c6-d49fe6cc7a26%40googlegroups.com
>> .
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a54f5360-1519-4a29-aa25-7cb9fe869c13%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[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 can 
> serialise save methods as part of the model for later use in migrations. If 
> you want to use complex save logic in migrations, you'll have to copy it 
> into the migration file (which also means the migration will keep working 
> as originally written if you later change what the save method does).
>
> Andrew
>
>
> On Fri, Dec 20, 2013 at 4:15 PM, Val Neekman  > wrote:
>
>> South (latest) has a limitation where it ignores a custom save() method 
>> in the model class.
>>
>> I am wondering if that is going to be true for the new South in the core 
>> in Django 1.7?
>>
>> Thanks,
>>
>> Val
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CADy_H8ERxnyrzf5UGOTPt1%3DUmj46himOBJ3w%2BBrxL49u_E3qyA%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c219ae48-16fe-4149-91c6-d49fe6cc7a26%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Christian Schmitt]

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:
>
>
>
> 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 
>> tend to be well-maintained. I wouldn't worry about the owner field until 
>> you are looking at the ticket and can see the full context of recent 
>> activity. If it turns out someone else _is_ actively working on it, no 
>> harm done, move on to a different one. 
>>
>
> Thats one of my biggest problem. There are way to many things that 
> interesting me technically. The problem is always the time. i don't owe 
> that much time. so "smaller" issues would be great, especially to find out, 
> what interests me.
>
> This is my updated query: 
>
> https://code.djangoproject.com/query?status=new_patch=0=Accepted=Someday%2FMaybe=assigned=new_better_patch=1_patch=1=Accepted=Ready+for+checkin=Someday%2FMaybe=id=summary=status=owner=type=component=priority
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b4b1a28b-5663-4196-b61b-9d583c50b6f2%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Christian Schmitt]

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 
> tend to be well-maintained. I wouldn't worry about the owner field until 
> you are looking at the ticket and can see the full context of recent 
> activity. If it turns out someone else _is_ actively working on it, no 
> harm done, move on to a different one. 
>

Thats one of my biggest problem. There are way to many things that 
interesting me technically. The problem is always the time. i don't owe 
that much time. so "smaller" issues would be great, especially to find out, 
what interests me.

This is my updated query: 
https://code.djangoproject.com/query?status=new_patch=0=Accepted=Someday%2FMaybe=assigned=new_better_patch=1_patch=1=Accepted=Ready+for+checkin=Someday%2FMaybe=id=summary=status=owner=type=component=priority
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f427b3cb-fbde-4b5d-9b1b-79cb2c3b7301%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Christian Schmitt]

No FastCGI isn't a bad protocol. But it's not recommand to deploy Python 
Application's with FastCGI. FastCGI is good for deploying PHP or even 
sometimes Golang (but here, the plain Webserver is better).
But! FastCGI is a low level protocol and WSGI tries to get rid of that.
Flup is just a server/middleware that makes a WSGI based Application to a 
SCGI/FCGI one. It's never recommand to use a low level api, when you don't 
have to.
Also people who deployed on FastCGI should change that behavior to 
mod_wsgi, and there are a shitload of hosters that already supporting 
mod_wsgi, so it's 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: 
> > 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 running. 
> > You could strip that down so easily and compile it, even on CentOS. 
>
> The thing that people seem to be missing here is that FastCGI is not 
> obsolete. There is currently no other deployment technology that can 
> reasonably replace it for the people who make use of it (with the 
> possible exception of SCGI). 
>
> FastCGI is essential in environments where websites are hosted that use 
> different languages and frameworks. WSGI is Python only and therefore 
> would require two deployment methods based on technology used increasing 
> maintenance overhead and ultimately cost. 
>
> uWSGI is starting to get a few more plugins written for it for other 
> languages but it is still lacking somewhat (and when I have a couple of 
> days spare I may well work on adding some of what I need). 
>
> Nor is FastCGI obsolete. People in the technology field suffer from a 
> problem were old = bad when in fact old means stability which is crucial 
> for important production sites. Flup may well have issues and I would be 
> more than happy to work on fixing those issues but lets not mistake 
> problems with Flup as problems with FastCGI itself. Flup is an 
> implementation. FastCGI is a protocol and the protocol is just fine. 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Christian Schmitt]

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 running.
You could strip that down so easily and compile it, even on CentOS.

Maybe it's better to improve the Docs about Apache2 / nginx / HAProxy 
deployment with mod_wsgi than supporting FCGI.
I mean some things like that:

> http://ontwik.com/python/django-deployment-workshop-by-jacob-kaplan-moss/

I think that these things are really important. Howto get from development 
to Production, with security.
(btw. the talk is from 2011 and some things aren't up 2 date, like the 
pgpool single point of failure thing, etc. today you could really well 
deploy a good enviroment or 2 or more servers where you don't have any 
single point of failure where you don't need to add any extra line of code. 
okai maybe you need to find a good way to hold cookies in a good memory 
based database, that you could share them between machines, but that is the 
only thing you should care about, since that is the only you shouldn't hold 
in your legacy database.)

Am Sonntag, 14. Juli 2013 21:17:00 UTC+2 schrieb Florian Apolloner:
>
> Hi,
>
> I'd like to get rid of everything FCGI-specific in Django sooner or later 
> (rather sooner). Flup isn't maintained since a long time and there is no 
> ticket tracker to report stuff. Graham pointed out that if someone wants to 
> use FCGI they can use 
> http://uwsgi-docs.readthedocs.org/en/latest/Options.html#fastcgi-socketwhich 
> doesn't even require flup, which sounds like a good compromise to me. 
> I'd need some help for the docs from some uWSGI users, since I have no idea 
> about it ;)
>
> Thoughts, objections?
>
> Cheers,
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Localization and Forms with Currencyfields / Value

[Christian Schmitt]

The Thing is, some Application that dealing with money have thousand 
separator, and fields without. So it won't work. I've wrote my own Field 
since, I need to deal with both, but I think this is a feature that should 
be included in the core of django.
Or even something like models.DecimalField(grouping=True) not sure how but 
I think its not good to turn THOUSAND_SEPERATOR on globally.
I've encountered localization problems with some template filters 
especially with intcomma.

Am Samstag, 15. Juni 2013 16:31:21 UTC+2 schrieb Aymeric Augustin:
>
> Hi Christian,
>
> Could you 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...@briefdomain.de> 
> wrote:
>
> 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 Django have a CurrencyField in core or even 
> better functions for dealing with currency values.
>
> I mean I would maybe contribute something to django, but maybe i'm too 
> scared that my code isn't correct or even not that good to get contributed.
> It would just be another improvement for django when the handling of 
> Currencies would be less worse than it is now.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Localization and Forms with Currencyfields / Value

[Christian Schmitt]

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 Django have a CurrencyField in core or even 
better functions for dealing with currency values.

I mean I would maybe contribute something to django, but maybe i'm too 
scared that my code isn't correct or even not that good to get contributed.
It would just be another improvement for django when the handling of 
Currencies would be less worse than it is now.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.