Re: Django git guidelines
I noticed this hasn't made it to master yet. Could it? I'm running sprints and there's a bit of confusion on how to contribute to git. Cheers, Jeremy On Thu, Jun 7, 2012 at 9:53 AM, Aymeric Augustin wrote: > On 6 juin 2012, at 21:09, Anssi Kääriäinen wrote: >> I am sure there is still a lot to polish. I might have tried to change >> too big portion of the docs in one go. Still, I would like to commit >> what I have tomorrow, so that the sprinters at djangocon have the >> possibility to use the guidelines and begin the polishing work. >> Alternatively, if it is possible to build the docs and make them >> available somewhere for the sprinters, I could wait for reviews from >> the sprinters, then commit the code early next week. This would make >> for a really good review for the guidelines. >> >> The work is available from: >> https://github.com/akaariai/django/tree/django_git_guidelines >> or for compare view: >> https://github.com/akaariai/django/compare/django_git_guidelines > > Hello Anssi, > > As discussed on IRC, I reviewed your patch, copy-edited it a bit slightly and > committed it. > > This can definitely still be polished, but we had to start somewhere, and > it's done. We'll adjust it as necessary. > > Many thanks for your work! > > -- > Aymeric. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Git questions
On Fri, Jun 8, 2012 at 7:57 AM, Anssi Kääriäinen wrote: > On 8 kesä, 17:28, Luke Plant wrote: >> First, thanks so much to Aymeric and Anssi and others for the >> contribution guidelines, they're very helpful. >> >> I've got some questions that are due to my ignorance of git (I have >> managed to avoid it as something I need in daily use, I still think it's >> got a brain-damaged UI...) >> >> In this section: >> >> https://docs.djangoproject.com/en/dev/internals/contributing/committi... >> >> it's written you can use this: >> >> git push --dry-run upstream master >> >> to check outgoing changes. However for me the output of that command is >> a short and very unhelpful message, something like this: >> >> To g...@github.com:django/django.git >>45d4331..2d5f9e4 master -> master > > The idea is you do next "git log" to see what are the actual changes. > >> The alternative for checking outgoing changes that I've found is using log: >> >> git log -p upstream/master..master >> >> However, I've found this doesn't work as I expect sometimes, because >> somehow after a pull, the branch pointer for 'remotes/upstream/master' >> has not been updated to where I expect it to be (the last commit pulled >> from upstream), but is left where it was. I've observed this several >> times. If I do 'git fetch upstream', rather than 'git pull upstream >> master', then the pointers always update, but I thought the whole point >> of doing 'pull' was 'pull=fetch then merge'. Am I doing something wrong? Actually, I think what is going on here is that git-pull does a fetch-and-merge of whatever the branch is set to track upstream. This may not be the branch you hope/expect it to be. " When a local branch is started off a remote-tracking branch, git sets up the branch so that git pull will appropriately merge from the remote-tracking branch. This behavior may be changed via the global branch.autosetupmerge configuration flag. That setting can be overridden by using the --track and --no-track options, and changed later using git branch --set-upstream. " If you create a local branch from another local branch, I believe the new branch gets the same upstream branch that the original local branch had. To see what branch your local is tracking (if any): $ git branch --list -vv For example, my output there includes: master 76d5daa [upstream/master] Changed `manage.py shell`'s help text to reflect that it can invoke bpython. virtual_signals c8dc85d [votizen/virtual_signals: ahead 1] Clarify args If you find your local is on the wrong branch, you can set it like so: git branch --set-upstream -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: pre_init/post_init vs. performance
On Sun, Jul 15, 2012 at 11:07 AM, Jeremy Dunck wrote:
>
> That is indeed what I meant, but I think Anssi's probably right that
> this belongs in contribute_to_class instead of a new adhoc thing in
> ModelBase.__new__.
>
> I'll take a swing at making this change.
>
> Opened related ticket: https://code.djangoproject.com/ticket/18627
OK, I have a very rough cut w/ all tests passing here:
https://github.com/jdunck/django/tree/18627_pre_init
I poked in a flag, sys.JDUNCK_NEW, which can be turned on/off for old
and new implementation - this is poked in at django.__init__
To test performance, using tests/test_sqlite modified with:
INSTALLED_APPS = [
'regressiontests.model_fields'
]
and
DATABASES['default']['name'] = ':memory:'
Testing the pre_init hook:
timeit.Timer("""
for i in names:
models.Person(name=i)
""", """
from django.core.management import call_command
from regressiontests.model_fields import models
call_command('syncdb')
names = [str(i) for i in range(1000)]
""").timeit(1000)
Under the existing signal usage: 24.609718084335327
Under the new approach avoiding signal usage: 18.074234008789062
I'd expect post_init to be a smaller gain since the destination
function has more overhead, but still a gain.
Note that the pre_init and post_init signals are still fired -- it's
just that django as-shipped won't use any listeners on them, so the
Model.__init__ performance improves.
In some cases, object construction currently is larger than query time
- a simple 'select x from y limit 1000' would have similar overhead to
this. Also, note that this gain would be seen on all models in any
project using GFK or ImageField but no other pre_init or post_init
hooks - not just those models which have the fields. With this
switch, only the models with the hooking fields have the related
overhead.
Feedback welcome.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django git guidelines
On 18 juil. 2012, at 11:46, Jeremy Dunck wrote: > I noticed this hasn't made it to master yet. Could it? I'm running > sprints and there's a bit of confusion on how to contribute to git. Hi Jeremy, This was committed. It's under Docs > How to get involved > Working with Git and GitHub. https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/working-with-git/ Best regards, -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Optional operator index discussion
I'd like to open up a discussion on the possibilities of having a way to optionally specifying not to create operator indexes on CharField's when db_index=True. Based on the consensus from this discussion, I'll open up a ticket and if it is within my abilities, generate a patch. For background, ticket #12234 (https://code.djangoproject.com/ticket/12234) resulted in the creation of a second index for all CharField's and TextField's when db_index=True to enable LIKE queries to work as they should. However, there are many use cases where a CharField index is needed but adding a varchar_pattern_ops index (in PostgreSQL) results in a performance and storage space hit. In my case, The storage space difference was 550GB with varchar_pattern_ops indices and 300GB without. I don't have an exact statistic on the drop in insert speed, but it was noticeable. In my case, these varchar fields are of small width, generally 1 to 4 characters, and indexing is important on the complete field. However, it will never be the case that LIKE will be used to query for partial matches, so LIKE query speed isn't an issue, and an operator index is a performance/storage hit that isn't justified. I am working around the problem now with a custom Field class, but it seems to me that this is a feature that others may benefit from and wanted to solicit feedback and ideas for if it should be an option, and if so, what form it should take. Thanks much, Eric -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/NbYgWQVhBYEJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Optional operator index discussion
On Thu, Jul 19, 2012 at 2:19 AM, Eric Floehr wrote: > I'd like to open up a discussion on the possibilities of having a way to > optionally specifying not to create operator indexes on CharField's when > db_index=True. Based on the consensus from this discussion, I'll open up a > ticket and if it is within my abilities, generate a patch. > > For background, ticket #12234 (https://code.djangoproject.com/ticket/12234) > resulted in the creation of a second index for all CharField's and > TextField's when db_index=True to enable LIKE queries to work as they > should. > > However, there are many use cases where a CharField index is needed but > adding a varchar_pattern_ops index (in PostgreSQL) results in a performance > and storage space hit. In my case, The storage space difference was 550GB > with varchar_pattern_ops indices and 300GB without. I don't have an exact > statistic on the drop in insert speed, but it was noticeable. > > In my case, these varchar fields are of small width, generally 1 to 4 > characters, and indexing is important on the complete field. However, it > will never be the case that LIKE will be used to query for partial matches, > so LIKE query speed isn't an issue, and an operator index is a > performance/storage hit that isn't justified. > > I am working around the problem now with a custom Field class, but it seems > to me that this is a feature that others may benefit from and wanted to > solicit feedback and ideas for if it should be an option, and if so, what > form it should take. Broadly speaking -- yes, sounds interesting; the trick will be coming up with an API that *isn't* PostgreSQL specific. Off the top of my head, I would look at this problem as the problem of configuring the types of index that are to be created. db_index is currently treated as a boolean yes/no; if you say yes, it creates an index (or, in the case of PostgresSQL, indices); if you say no, it doesn't. To me, what you're talking about is turning a True/False option into something that can be explicitly configured (with some sort of fallback so that "True" is the default index collection). This would need to be functionally driven -- e.g., "I want to add an index that allows for partial matches", or "I want to add a case-insensitive index" -- not exposing literal database syntax or options. On some databases, some of these "functions" would be no-ops, or subsumed by other index functions (so MySQL, for example, will only create one index on CharFields). There is an analogous ticket around dealing with adding composite/multicolumn indices: https://code.djangoproject.com/ticket/5805 I don't know if there's any potential for overlap when it comes to the API here, but it might be worth exploring. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
