Re: Annotate date intervals or ranges

[Josh Smeaton]

FYI I'm implementing date_trunc based transforms in this 
patch: https://github.com/django/django/pull/6243

Since the transform names "__month" "__year" etc are already taken by the 
Extract based transforms I've not yet implemented a lookup_name so that 
they can be used on the left hand side of filters 
(.filter(created__monthtrunc=..). If there is a decent proposal for trunc 
based lookup names, it'll be very easy to add them on.

So here's my request for proposal. Are there any good lookup names that we 
can give trunc based date transformations? If there are no good suggestions 
before this is ready for commit, that's ok. We can always add lookup_name 
properties at a later datetime (sorry).

Cheers

On Friday, 4 March 2016 10:08:47 UTC+11, Josh Smeaton wrote:
>
> A somewhat related ticket: https://code.djangoproject.com/ticket/25774 
> which attempts to make current datetime transforms/expressions public. 
> These focus mainly on EXTRACT() type transformations, but there's certainly 
> a place for date_trunc type transformations too. Feel free to create a 
> ticket proposing such expressions if one does not already exist.
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20ba3084-559a-49d9-b7ff-6de45639ded6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: TransactionManagementError is raised when autocommit …

[Tore Lundqvist]

Hi, Aymeric

Thanks for your extensive reply.

I'm sorry that I just throw in that comment about timed out connections 
without enough information for you to actually respond to it.

an example of when it happens is when:

Starting with auto commit on.
transaction.set_autocommit(False)
... a lot of time passes without the connection being used so it times 
out
close_old_connections()

Now autocommit is on again. I'm not saying that it's a bug, but it's 
inconvenient.

I have already seen your talk at DjangoCon and it's very good and I have 
recommend it to others too.

I think the new transaction management API makes a lot more sense than the 
old one. The problem is that the legacy code uses COMMIT side effects to 
manage disk writes and avoid deadlocks, securing an adequate transactional 
integrity is often not an issue. With explicit commit statements it's easy 
to control when commit is preformed but with atomic blocks you get the 
commit implicitly when (if they are nested) the outermost block ends, that 
makes it hard to grantee a commit from deep down a call stack. So I'm 
trying to disable or at least use as little as possible of Djangos 
transaction management for this code. Other parts of the system can use the 
transaction management as intended.

Cheers
Tore

Den söndag 6 mars 2016 kl. 20:25:09 UTC+1 skrev Aymeric Augustin:
>
> Hi Tore, 
>
> > On 05 Mar 2016, at 20:41, Tore Lundqvist > 
> wrote: 
> > 
> > Regardless of the particular problem I have got shouldn't it be possible 
> to disable Djangos transactional management if you want to? 
>
> It's possible. It’s documented. 
>
> https://docs.djangoproject.com/en/1.9/ref/settings/#autocommit 
>
> https://docs.djangoproject.com/en/1.9/topics/db/transactions/#deactivate-transaction-management
>  
>
> > Is not transaction.set_autocommit(False) doing that? 
>
> It has the same effect as the AUTOCOMMIT option but you have to run it on 
> every new connection. 
>
> > Is it not surprising to get a TransactionManagementError when you have 
> turned of the transaction management? 
>
> As documented, “turning off Django's transaction management” means “you 
> have to understand exactly what happens and, most often, implement yourself 
> a significant part of Django’s transaction management tools”. 
>
> The ORM still needs to be aware of the current transaction state e.g. for 
> "create or update” operations, for multi-table inserts when inheritance is 
> used, etc. There’s no way to make the ORM not care about transactional 
> integrity at all. 
>
> > There is also another broken thing with set_autocommit(False) if the 
> database connection has timed out and is reconnected by Django, autocommit 
> is set to True again, that was kind of surprising and ugly to workaround. 
>
> It must be quite frustrating for you to keep ignoring the documentation 
> and the advice given by people who wrote the code, to make up arbitrary 
> theories on Django’s behavior, to realize that this isn’t the actual 
> behavior, and to fantasize that it’s a bug. I’m not sure how we can discuss 
> on such terms. 
>
> For this discussion to move forwards, you'll have to read and understand 
> the documentation. If you need to go further and get a deeper understanding 
> of how Django ended up there, look at this mailing list’s archives. I 
> explained my reasoning when I implemented Django’s current transaction 
> management in Django 1.6. I explained some choices again in several threads 
> since then. You may also be interested in my DjangoCon talks — the videos 
> are online. 
>
> I can’t say that the current system is perfect. I know its flaws better 
> than anyone else. However I will say that, until now, you haven't 
> demonstrated a sufficient level of understanding of its design or its 
> implementation to challenge them. 
>
> I’m sorry for the lack of a good upgrade path. If you read the history, 
> you’ll see why it was impossible to implement adequate transactional 
> integrity guarantees with the old APIs. Perhaps getting this perspective 
> will give you ideas to solves your upgrade problem? (Also, to be honest, 
> given the bugs in the old APIs, I’m skeptical that a system with 400 commit 
> statements in arbitrary locations actually provided the guarantees you 
> hoped for.) 
>
> In any case, that should give you a better idea of how to use Django’s 
> transaction management APIs and, if they're really unsuitable for your 
> needs, how to do things differently. For what it’s worth, every 
> constructive discussion I’ve had on this topic has resulted in the removal 
> of shaky transaction management code and the implementation of a much more 
> straightforward system based on the new APIs. 
>
> It’s very hard to help you further without seeing some code. I have very 
> little idea of what problems you’re hitting. I could infer one of your 
> issues when we were discussing on Trac because it’s a common one and, 
> admittedly, a weakness of the current APIs. Then yo

Re: [Feature Request] Orderable ArrayAgg and StringAgg in contrib.postgres.aggregates

[Tim Graham]

Ticket for JSON_AGG: https://code.djangoproject.com/ticket/26327

On Thursday, January 7, 2016 at 5:45:03 PM UTC-5, Josh Smeaton wrote:
>
> Seems reasonable enough to me. Expressions already support generating an 
> ORDER BY clause by calling .asc() or .desc() on them. That'd allow your 
> proposed API to support:
>
> Model.objects.aggregate(ArrayAgg(some_field, order_by=
> F('some_field').asc()))
>
> Or any other expression. Consider that any ordering added within *may* 
> need to be contributed to GROUP BY, but I haven't read the documentation to 
> say that is a requirement.
>
> Feel free to open a ticket in Trac to track the feature. If you're also up 
> for implementing it (..and testing.. and documenting..) I'm quietly 
> confident that it'll be fairly straight forward to add, given familiarity 
> with Expressions API.
>
> Additionally, if you think json_agg and json_object_agg should be 
> implemented, you can open a feature ticket on Trac for those too. 
>
> Regards,
>
> On Friday, 8 January 2016 00:46:52 UTC+11, Floris den Hengst wrote:
>>
>> The excellent ArrayAgg and StringAgg Postgres-specific aggregates were 
>> introduced in contrib.postgres in Django 1.9 and I've been quite happy 
>> using them here and there.
>> Thanks for the keeping Django awesome!
>>
>> The documentation 
>>  of 
>> Postgres 9.0 first mentions the possiblity of ordering the results within 
>> such aggregations.
>> This could be useful in some cases.
>> For example: it could make sense to perform the StringAgg in 
>> lexicographical order in some cases.
>>
>> The simple format of ordering the aggregation result in SQL is quite 
>> simple:
>> SELECT ARRAY_AGG(some_field ORDER BY some_field ASC) FROM table;
>> SELECT ARRAY_AGG(some_field ORDER BY some_field DESC) FROM table;
>> SELECT ARRAY_AGG(some_field ORDER BY other_field ASC) FROM table;
>>
>> It would be nice if the above would be supported as follows:
>> Model.objects.aggregate(ArrayAgg(some_field, order_by='some_field'))
>> Model.objects.aggregate(ArrayAgg(some_field, order_by='-some_field'))
>> Model.objects.aggregate(ArrayAgg(some_field, order_by='other_field'))
>> where order_by is an optional parameter. If it not specified, behavior 
>> can remain unchanged from the current implementation.
>>
>> Note that the documentation for Postgres >= 9.3 also mentions 
>> json_agg ordering and Postgres >= 9.4 mentions json_object_agg as well.
>> I'm unsure whether these should be included as well as I couldn't find 
>> the matching implementation in the ORM atm and have no knowledge on plans 
>> in that direction.
>>
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9969256a-a730-42c4-84c8-b5fec7a9388f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: TransactionManagementError is raised when autocommit …

[Tore Lundqvist]

Hi, Shai

As far as I know your not allowed to do a transaction.rollback() in an 
atomic block so I don't seen how this is different from doing a 
transaction.commit()


Den måndag 7 mars 2016 kl. 08:23:09 UTC+1 skrev Shai Berger:
>
> Hi Tore, 
>
> You should be able to get what you want be replacing your commits by 
>
> connection.cursor.execute("commit"); transaction.rollback() 
>
> or equivalents (caveat: untested). 
>
> This looks like a very hackish thing to do, code I wouldn't put in 
> production. 
> And it should. 
>
> Shai. 
>
> On Saturday 05 March 2016 21:21:27 Tore Lundqvist wrote: 
> > Thanks for the suggestion! 
> > I have been thinking of workarounds with multiple db aliases and it 
> would 
> > solve the problem I described but in reality the code I'm working with 
> is 
> > much more complex and has around 400 explicit commits. It all worked 
> great 
> > in Django 1.4 but since we upgraded to 1.8 (and got the new transaction 
> > management) I have been forced to make ugly workarounds and patch Django 
> > this time. 
> > 
> > Den lördag 5 mars 2016 kl. 19:41:59 UTC+1 skrev jdunck: 
> > > I've had this scenario before - you have two interleaving units of 
> work 
> > > (through composition of code from different sources or concerns).  You 
> > > want progress recorded for one unit of work, but perhaps not the 
> other. 
> > > Without django, you'd have two open connections.  In my experience the 
> > > simplest way to accommodate this is to have two DB aliases pointed at 
> > > the same DB.  Set one to be a test mirror of the other.  Use different 
> > > aliased connections for the two concerns.  Then you can use atomic (as 
> > > suggested and typical). 
> > > 
> > > On Fri, Mar 4, 2016 at 2:11 PM, Tore Lundqvist  > > 
> > > > wrote: 
> > >> I don't what all updates to be in one commit each so I can't wrap 
> just 
> > >> the update with a atomic block I would need to have it over a bigger 
> > >> chuck of code. That chunk might call a subrutin that also needs a 
> > >> commit and if I wrap that update in a atomic block that atomic block 
> is 
> > >> nested and results in a save point which is useless. 
> > >> 
> > >> Den fredag 4 mars 2016 kl. 22:46:30 UTC+1 skrev Aymeric Augustin: 
> > >>> If you do what Simon and I suggest, you should get the result you 
> just 
> > >>> described. If you don’t, please explain what happens. 
> > >>> 
> > >>> Within a transaction — and disabling autocommit means you’re within 
> a 
> > >>> transaction — transaction.atomic() uses savepoints. 
> > >>> 
> > >>> Note that in Django 1.6, after set_autocommit(False), you couldn’t 
> use 
> > >>> transaction.atomic(). That was fixed in 1.8 (I think). 
> > >>> 
> > >>> 
> > >>> On 04 Mar 2016, at 21:21, Tore Lundqvist  wrote: 
> > >>> 
> > >>> Hi, Simon 
> > >>> 
> > >>> No, I would need to wrap everything i a atomic block to start the 
> > >>> transaction and it's only when that outermost atomic block exits 
> that I 
> > >>> actually get a commit the nested ones just makes save point. 
> > >>> 
> > >>> /Tore 
> > >>> 
> > >>> Den fredag 4 mars 2016 kl. 21:09:17 UTC+1 skrev charettes: 
> >  Hi Tore, 
> >  
> >  Is there a reason you can't simply wrap your updates in a 
> >  `transaction.atomic()` blocks? 
> >  
> >  You should be able to avoid deadlocks and control exactly when data 
> is 
> >  written to disk 
> >  with this construct. 
> >  
> >  Simon 
> >  
> >  Le vendredi 4 mars 2016 15:02:45 UTC-5, Tore Lundqvist a écrit : 
> > > Reply to comments in ticket: 
> > > https://code.djangoproject.com/ticket/26323#comment:10 
> > > 
> > > Hi, 
> > > 
> > > @Aagustin: I get your point but in the code I'm working on there 
> is a 
> > > lot of transaction.commit(), not to handle transactions but to 
> manage 
> > > when data is written to disk and to avoid deadlocks. Running in 
> > > autocommit mode does not work, its slow and sometimes the commits 
> is 
> > > used to save in a known good state. So I disable autocommit with 
> > > transaction.set_autocommit(False) and run the code with explicit 
> > > commits in it and than turn autocommit on again. 
> > > 
> > > The documentation for set_autocommit says "Once you turn 
> autocommit 
> > > off, you get the default behavior of your database adapter, and 
> > > Django won’t help you." That is what I want and thats way I think 
> > > that the TransactionManagementError should not de raise if your 
> not 
> > > using atomic blocks. 
> > >> 
> > >> 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-develop...@googlegroups.com . 
> > >> To post to this group, send email to django-d...@googlegroups.com 
> > >> . 
> > >> Visit this group at htt

Re: [Question] jsi18n - get_javascript_catalog a bit obscure?

[Tim Graham]

For posterity, ticket is https://code.djangoproject.com/ticket/26328.

On Friday, March 4, 2016 at 4:54:06 PM UTC-5, Tim Graham wrote:
>
> Please read https://code.djangoproject.com/
>
> On Friday, March 4, 2016 at 4:47:39 PM UTC-5, Cristiano Coelho wrote:
>>
>> Where do I get an account for Trac tickets? :) I guess I should still 
>> open a ticket first
>>
>> El viernes, 4 de marzo de 2016, 18:31:41 (UTC-3), Tim Graham escribió:
>>>
>>> Sure, I mean... my impression as indicated by the lack of response to 
>>> the thread is that no one provides much expertise in javascript_catalog() 
>>> these days (although it's only been a couple days). I don't use it myself 
>>> so I do my best to review proposed changes and then we wait for bug 
>>> reports. Maybe this will be the start of your journey to being that expert.
>>>
>>> Quoting https://github.com/django/django/blob/master/CONTRIBUTING.rst, 
>>> "non-trivial pull requests (anything more than fixing a typo) without Trac 
>>> tickets will be closed! Please file a ticket 
>>>  to suggest changes."
>>>
>>> On Friday, March 4, 2016 at 4:11:08 PM UTC-5, Cristiano Coelho wrote:

 Would a pull request be accepted? Does it need to be a new branch even 
 if the change is just a few lines? Does it need an open ticket first?

 El martes, 1 de marzo de 2016, 22:26:00 (UTC-3), Cristiano Coelho 
 escribió:
>
> Looking through git history seems like the "always load english 
> translations" code is quite a few years old.
>
> There's a 5 y.o ticket in here: 
> https://code.djangoproject.com/ticket/16284
>
> Which leads to here: https://code.djangoproject.com/ticket/3594 with 
> a fix that adds the "discard if english not found" which doesn't resolve 
> the issue completely if you actually have english translations but it is 
> not the default language.
>
> There's also a link to here: 
> https://groups.google.com/forum/#!topic/django-developers/1X_tPbhG_NQ 
> proposing a change with no replies at all.
>
> I couldn't really understand why is it that the hardcoded english 
> language can not be removed from here.
>
> In my opinion the code should be slightly changed to only load the 
> default language rather than english (and as long as the requested 
> language 
> is not the same as the default one) as fallback, so it can match the 
> actual 
> server side behaviour, which will load the configured language (at 
> settings) as a fallback language as long as it is different from it (an 
> from english, which makes sense because django text ids are all in 
> english).
> This change could however affect people that relies on always having 
> an english translation as fallback when the configured default language 
> is 
> not english (does this even make sense? Would anyone do that?)
>
> After this change is done, there could be an improvement (for both js 
> and server side translations) that some people might find useful, rather 
> than always falling back to the default configured language, you could 
> have 
> a map of fallbacks, for example, if the user requests a portuguese 
> language, but you only have english (default) and spanish (secondary), it 
> makes more sense to fallback to spanish rather than english, but if the 
> user requests russian, it makes more sense to fallback to english.
>
> El martes, 1 de marzo de 2016, 21:29:42 (UTC-3), Tim Graham escribió:
>>
>> Have you tried looking through history with git blame to find related 
>> tickets? Another tip is to search Google with a query like 
>> "javascript_catalog site:code.djangoproject.com". This will let you 
>> find tickets to see if the issue was raised before. This is how I try to 
>> answer questions like this since many of the original authors are no 
>> longer 
>> active (or at least, you can find the person who authored the code in 
>> question and try a more directed query like a ping in IRC).
>>
>> On Tuesday, March 1, 2016 at 6:23:38 PM UTC-5, Cristiano Coelho wrote:
>>>
>>> Maybe I wasn't clear neither, but the main issue is this: when using 
>>> a language equals to the default one, and if that language does not 
>>> define 
>>> any translation text (because ids are the same as values so it is not 
>>> necessary), the server side translations will always correctly return 
>>> the 
>>> translated texts, while the javascript won't because it always has an 
>>> english fallback.
>>> Also the code I provided should actually load the default language 
>>> translations as well (but not the english ones!) to make it behave 
>>> exactly 
>>> as the server side translations.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django dev

Re: Problems with cache.get_or_set behaviour

[Tim Graham]

A solution is proposed in https://code.djangoproject.com/ticket/26332. It 
looks reasonable to me. Feel free to give your feedback there.

On Sunday, February 28, 2016 at 5:26:50 PM UTC-5, Raphael Michel wrote:
>
> Hi, 
>
> I just experienced the following behaviour and would like to ask for 
> your opinion whether I should file this as a bug or whether this is 
> intended behaviour. I today had the pleasure to work with a crashed 
> memcached deaemon that could not restart because of a permission 
> problem. In this case, django, using the backend 
> 'django.core.cache.backends.memcached.MemcachedCache' 
> behaved as follows: 
>
> >>> cache.set("foo", "bar") 
> >>> cache.get("foo") 
>
> So it fails silently and all get calls will return None. That is 
> sensible behaviour if one does not want cache calls to raise 
> exceptions. However, when using the new get_or_set() method from Django 
> 1.9, I got 
>
> >>> cache.get_or_set('foo', default='bar') 
> 0 
>
> This really is suprising to me. For any reasonable usage I can think of, 
> I would expect get_or_set() to return the specified default value. 
>
> When looking at the implementation of BaseCache.get_or_set, one finds 
> that in the case of the value not existing, the value is saved 
> and returned as follows: 
>
> if val is None: 
> val = self.add(key, default, timeout=timeout, version=version) 
> if val: 
> return self.get(key, default, version) 
> return val 
>
> I assume that the last get() call is there to prevent a possible 
> race condition with other processes that is updating the key right 
> after our add statement. 
>
> However, if val is for some reason not evaluating to True, the result 
> of add() is being returned. add() is documented as returning True or 
> False and I don't think it makes any sense to return True/False from a 
> method that is expected to return a cached value or a default value. 
>
> I think we need a better behaviour of get_or_set() if add() fails but 
> I'm unsure how it exactly should look like, otherwise I would have 
> prepared a patch. 
>
> Cheers 
> Raphael 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7a3e5620-22bf-4646-aa42-3bb90a1b8785%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should tutorial start with minimal Django?

[Tim Graham]

I think it could be useful to document that you can use Django with such a 
minimal setup. My preference wouldn't be to put it in the tutorial but 
maybe it has a place in docs/topics/overview.txt or similar.

On Tuesday, March 1, 2016 at 8:07:38 PM UTC-5, Curtis Maloney wrote:
>
> When we were teaching MelbDjango, I did start by writing views in the 
> root urls.py  this avoided students having to create a bunch of 
> files and apps and references and imports and... 
>
> For some of the students transitioning from PHP, it was much easier to 
> deal with only learning one thing at a time... 
>
> However, we didn't go quite so far as that example... still using 
> "startproject" etc. 
>
> -- 
> Curtis 
>
> On 02/03/16 12:03, Bobby Mozumder wrote: 
> > Hi, 
> > 
> > Here’s an example of minimal Django, where one can output run an full 
> site from a single file: 
> >   https://github.com/rnevius/minimal-django 
> 
>  
> > 
> > The author made the comparison to Flask. 
> > 
> > I believe the tutorial should start out with this, as the initial Part 
> 0, to introduce the audience to the framework, before introducing 
> apps/models/subdirectories/etc.  I think a lot of people are turned off by 
> the heavy-handed immediate introduction of many files and directories of a 
> Django setup - I know I was when I first started with Django. 
> > 
> > Anyways just putting this out there. 
> > 
> > -bobby 
> > 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ec24375e-f673-4c12-81da-2fca533650ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[Tim Graham]

One idea (and it could be a terrible one) after a few minutes of thinking 
about it is an API similar to the query lookup/tranform API where you could 
write something like:

from django.db import models
models.CharField.register_formfield(MyCustomFormField)

which would make all subsequent CharFields use that form field. I guess you 
could already monkeypatch models.Field.formfield to achieve a solution like 
that, but it requires copying/pasting the existing methods just to replace 
the hardcoded form classes.

I'm not sure how my idea could work in the case of model fields like 
BooleanField which have the possibility of more than one form field.

On Tuesday, March 1, 2016 at 1:57:16 PM UTC-5, is_null wrote:
>
> Hi all, 
>
> Currently, the model field defines the default form field that's used 
> by the modelform metaclass. It would be nice if an external app could 
> overwrite this. 
>
> For example, a user installs an app which provides a more elaborated 
> relation select field. They configure the app to be able provide a 
> better form field or widget to select a particular model. 
>
> Now, it's a bit boilerplate to override the default generated form 
> field for a relation to that model in every modelform, as such: 
>
> class FirstForm(forms.ModelForm): 
> group = BetterField(your_options) 
>
> class SecondForm(forms.ModelForm): 
> main_group = BetterField(your_options) 
>
> # and so on 
>
> Currently, forms.ModelForm will use a form field that's known to work 
> by default. It does so by delegating that logic to the model field 
> methods such formfield() & friends. 
>
> Perhaps it would be an improvement if forms.ModelForm would be able to 
> use a form field that's *best* by default. "Best" here, is defined by 
> the project: what optional apps are installed and what configuration 
> they have. 
>
> For example, some apps will focus on providing a specific business 
> logic field, virtual or not (ie. generic many to many, array field, 
> tagfield ...), and other apps would focus on specific UX 
> (autocompletion, popup selection like raw_id_fields, other kind of 
> AJAX widgets). Gluing these apps in a projects is always the same, 
> from a project to another. If this kind of glue could be encapsulated 
> in another app, and made available in forms.ModelForm to improve 
> defaults, then users would have more time to work on what makes their 
> project different, rather than the same boilerplate code over and over 
> again. 
>
> I've been experimenting with ways to mitigate this issue for a few 
> years now, and here's what I came up with: 
>
> - allow a form field to override the model field's default saving 
> logic, as the input format may change it: 
> ModelField.value_from_object(), ModelField.save_form_data() and 
> ModelField.save_relation_data() should be overidable by the form 
> field, 
> - allow an app to register "form field factory callbacks" to 
> ModelFormMetaclass 
>
> I've implemented all that in a separate app and experimented with it 
> for a while, and TBH it works and it's okay to have this in an 
> external app rather than in Django itself (PoC: 
> https://github.com/jpic/xmodelform ), even thought it implies that the 
> user has to override everything to use this ModelForm by default 
> (admin, views, forms ...), this is not known to have killed any kitten 
> so far. Unless some point out that it would be good to have it in 
> Django, I'd work on it in a separate app  
>
> BUT, before I go all-in with this and make users use it by providing 
> it as the "official way", there's still one thing that fails to 
> convince me that it's the way to go. Something that may seem 
> completely unrelated, because it's a completely different way to go, 
> but solves the same issue: shouldn't effort be put in making a proper 
> way to change model fields from an external app ? 
>
> Related research on this has been started already apparently, with 
> django-swappable-models. It seems like work has been started to enable 
> model class override. While that's obviously overkill in the case I'm 
> talking about here, I'm wondering: would it be better to research a 
> way to enable external model field override, rather than the 
> form-oriented design exposed above (xmodelform) ? 
>
> I wish this could be avoided, but I recon that when you've tried 
> django-autocomplete-light v2's ModelForm, it's like eating the 
> defended fruit. Most of our userbase consider that v3 is not complete 
> and won't upgrade from v2 until they have this feature. I can 
> understand them, having a ModelForm that generates form fields which 
> are beyond "known to work" and have it generate "best" form fields for 
> a project without any boilerplate code is damn beautiful to see. 
> That's why this issue has been so fascinating to me and at least those 
> from the user base who stood up for that. 
>
> So, all this considered, what do you prefer, 0. research on overriding 
> the model field, or 1. on 

Re: Add support for relative imports in django.conf.urls.include()?

[Tim Graham]

How common are "heavily nested apps"? Is there anyone else reading this who 
would find this useful?

On Thursday, March 3, 2016 at 3:40:14 AM UTC-5, lamby wrote:
>
> This just made me realize that the whole problem can already be fixed from 
>> the user's perspective by importing the module instead of using string 
>> based imports
>>
>
>
> Not entirely convinced. Firstly it's extra stuff you have to explicitly 
> import which seems a style regression from the "oh just use these included 
> urls" that you get with the string-based import.
>
> Secondly, whilst it might look fine when you are doing it once, for 
> example:
>
> from django.conf.urls import url, include
>
> from . import views
> from .foo import urls
>
> urlpatterns = (
> url(r'', include(urls, namespace='foo')),
>
> url(r'^$', views.landing, name='landing'),
> )
>
> .. but the import dance get a bit nasty when you have multiple ones - you 
> have to alias each import:
>
> from django.conf.urls import url, include
>
> from . import views
> from .foo_app import urls as foo_urls
> from .bar_app import urls as bar_urls
> # etc.
>
> urlpatterns = (
> url(r'', include(foo_urls, namespace='foo')),
> url(r'', include(bar_urls, namespace='bar')),
>
> url(r'^$', views.landing, name='landing'),
> )
>
> This isn't an readabiliy improvement over using the string urls IMHO.
>
> Now, if only we could do the following:
>
> from . import views, foo_app, bar_app
>
> urlpatterns = (
> url(r'', include(foo_app.urls), namespace='foo')),
> url(r'', include(bar_app.urls), namespace='bar')),
>
> url(r'^$', views.landing, name='landing'),
> )
>
>
> /lamby
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7230c9c7-daaa-48b4-bfc3-f3c398a3f32b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Translate permission Django

[Tim Graham]

This has been discussed in several tickets 
(https://www.google.com/search?&q=translate+permissions+site%3Acode.djangoproject.com)
 
and mailing list threads (search the archives of this list for "translate 
permissions"). As far as I can tell, there's no clear solution at this time.

On Monday, February 29, 2016 at 10:03:12 AM UTC-5, Marcos Serrano wrote:
>
>
> 
>
>
> 
>
>
> El lunes, 29 de febrero de 2016, 10:20:36 (UTC+1), Marcos Serrano escribió:
>>
>> Hello,
>>
>> How to translate the default permissions django . Keywords ( Add, Delete ... 
>> )
>>
>>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2fac44f8-0d92-4830-a68d-6e4e48018921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Summer of Code Idea: Class-based [Object] Permissions

[Connor Boyle]

As I understand, some parts of Django-Rest-Framework 
 are being considered for 
integration into Django (please correct me if I'm mistaken). I'm not sure 
what specifically core plans to bring in, but in my opinion the feature 
that core Django needs the most from DRF has no direct connection to APIs 
or JSON: it's the extremely well-designed class-based permissions system 
.

For those who aren't familiar, the bottom line is that it's a system that 
allows the developer to run their own arbitrary code (in a clean, DRY, and 
readable way) to determine whether or not to return a 403 given a 
particular request and view. Any class-based view (with the provided mixin) 
can be assigned a tuple of permissions to check. In other words, it is the 
answer to our prayers.

Example:

MyApp/permissions.py: 
from rest_framework import permissions


class IsFromTexas(permissions.BasePermission):
'''Only allow users from Texas.
'''
def has_permission(self, request, view):
return request.user.state == 'TEXAS'

MyApp/views.py:
from MyApp.permissions import IsFromTexas
# Other imports

class MapOfTexasView(ClassPermissionsMixin, TemplateView):  # 
ClassPermissionsMixin does not actually exist yet
'''Return a map of Texas. Only allow users from Texas.
'''
permission_classes = (IsFromTexas,)
template_name = 'map_of_texas.html'

Checking against an object is trivial, and DRF's implementation makes it 
even easier and cleaner by providing a has_object_permission() method that 
gets passed the result of the view's get_object() if it has one (and makes 
it so the developer doesn't have to worry about accidentally calling 
get_object() multiple times).

I'm considering applying for Summer of Code with this (adding class-based 
permissions to Django) as the subject of my proposal. I would also add some 
features that DRF is missing, such as permission-checking on QuerySets, 
adding class-based permission checking to default class-based views, and 
dividing permissions into read and write.

A few questions for anyone who can answer them:

1. Is there any chance of getting this accepted as a feature? (through 
Summer of Code or otherwise)
2. Is this appropriate in scope and significance for a Summer of Code 
project? I'm guessing it would be relatively little actual code, but could 
potentially be a fundamental part of a huge number of projects made with 
Django.
3. I suspect that if this were to be added to Django core, we'd want to use 
a name other than 'permissions' given that Django already has its own 
permissions system that uses that name. How does 'authorizations' sound?


Connor Boyle
Macalester College

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d89393a0-e8f1-4398-9643-de4cc6d958da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: context = context.new(context)

[Tim Graham]

I guess this should go to django-users (usage questions). It's not clear to 
me how this is related to the development of Django itself. To increase the 
likelihood of getting an answer, make the code example more complete and 
find the commit in Django where the behavior changed. I can't answer the 
question in its current form.

On Thursday, February 18, 2016 at 1:16:19 PM UTC-5, John Bazik wrote:
>
> I'm looking at code that does this:
>
>  context = context.new(context)
>
> Prior to 1.7, I assume that worked since a context was a dict.  Now that 
> it's a stack, it breaks.
>
> I could suggest they use flatten:
>
>  context = context.new(context.flatten())
>
> but that's not exactly a copy, which is what I think they're after.
>
> What do you think they should be doing?
>
> John
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f47d724a-7edf-4506-93a9-b8751517897e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Admin hstore widget

[Tim Graham]

1. Merging something minimal always help to get feature requests. :-)

2. Could you be more specific about what you're looking for? All the 
existing documentation for style related stuff is at 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/.
 
I also thought of ticket https://code.djangoproject.com/ticket/14831. 

3. GitHub alias "elky" did the new admin look for 1.9: 
https://github.com/elky/django-flat-theme. I didn't verify the edits came 
in from that change, but what does "git blame" say?

On Sunday, February 7, 2016 at 6:11:46 PM UTC-5, Curtis Maloney wrote:
>
> So, I've been working on https://code.djangoproject.com/ticket/25197 
>
> I have it as part of my own project, with a view to contributing to core 
> once it's polished. 
>
> Currently it has basic functionality - a JS widget that fires on load, 
> hides the textarea, and produces a table of (name, value, actions). 
>
> It records original values for existing keys, so you can "undo" your 
> changes.  And I'm just adding detection of duplicate keys. 
>
> I also hope to add a "soft delete" so you can mark a key for deletion, 
> instead of immediately discarding it... 
>
> However, I've run into two problems: 
>
> 1. I'd like more input on the features people feel are essential. 
>
> 2. Is there a guide somewhere to styles and markup to be used in admin 
> templates? 
>
> 3. I plan to pull in another icon from FA, but it appears the one we 
> currently use for "inline delete" is customised from the original.  Does 
> anyone know who made these changes and how? 
>
> -- 
> Curtis 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f34888a2-d0cd-49be-837f-7036e16be97b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Spatial lookups for RasterField

[Tim Graham]

The index approach seems consistent with ArrayField's index transforms [0] 
so that seems okay to me.

[0] 
https://docs.djangoproject.com/en/1.9/ref/contrib/postgres/fields/#index-transforms

On Thursday, January 28, 2016 at 10:33:54 AM UTC-5, Daniel Wiesmann wrote:
>
> Hello Everyone
>
> I have been working on adding spatial lookups for the RasterField in the 
> GIS module.
>
> https://github.com/django/django/pull/5460#issuecomment-152606283
>
> I would like to get feedback regarding API design for the lookups.
>
> The challenge is that one needs to specify two parameters for the lookup: 
> the raster itself and a band index.
>
> I think everything should default to the first band, as many rasters only 
> have one band. For the special cases, an index has to be specified.
>
> On the right hand side (rhs) the proposal is to use a syntax similar to 
> the existing distance lookups, providing a tuple: (raster, band_index). 
> That follows previous art and should be ok.
>
> But on the left hand side (lhs) its less clear to me what to do.
>
> For instance, to compare band 2 from a raster field "elevation" with a 
> geometry, I can see two options
>
> A specify the index with a double underscore:
>
> elevation__2__intersects=geom
>
> B pass the band index on the rhs:
>
> elevation__intersects=(geom, 2)
>
> The current implementation in the PR above uses the second option. But I 
> have doubts because that mixes the lhs with the rhs.
>
> Here are my questions:
>
> - Are there other options for the api that shoudl be considered?
> - If not, which of the two approaches would be better?
>
> Thanks,
>
> Daniel
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9ffe0d81-ead1-4e9d-85c6-3eedd5912615%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL dispatching framework: feedback requested

[Tim Graham]

Hi Marten,

How are things going? Do you plan to make a push to merge this for 1.10? 
The alpha is scheduled for May 16. Are you still waiting for feedback? I 
think writing documentation would certainly facilitate that. Also, if 
there's any chance to break the existing commit into some smaller logic 
chunks/features to make review and merging easier, that would certainly be 
welcome from my perspective.

On Thursday, January 14, 2016 at 2:06:52 PM UTC-5, James Addison wrote:
>
> Marten,
>
>
> As you likely remember, I've been running your code for a few months now, 
> overall it's been pretty good. I mentioned some time ago that the list of 
> URLs displayed with `DEBUG=True` when triggering a 404 is sometimes empty, 
> or partially empty. This still happens for me, and I believe it has 
> something to do with using scheme/domain constraints - here are mine:
>
> class ConstraintBase(Constraint):
> """
> This exists purely as a way to ensure MRO mixin inheritance will work
> """
> def match(self, path, request=None):
> return path, (), {}
>
> def construct(self, url_object, *args, **kwargs):
> return url_object, args, kwargs
>
>
> class SchemeConstraintMixin(object):
> scheme = ''
>
> def match(self, path, request=None):
> if request and request.scheme == self.scheme:
> return super().match(path, request)
> raise Resolver404
>
> def construct(self, url_object, *args, **kwargs):
> url_object.scheme = self.scheme
> return super().construct(url_object, *args, **kwargs)
>
>
> class HostConstraintMixin(object):
> host = ''
>
> def match(self, path, request=None):
> if request and request.get_host() == self.host:
> return super().match(path, request)
> raise Resolver404
>
> def construct(self, url_object, *args, **kwargs):
> url_object.host = self.host
> return super().construct(url_object, *args, **kwargs)
>
>
> class SchemeHostConstraint(SchemeConstraintMixin, HostConstraintMixin, 
> ConstraintBase):
> def __init__(self, scheme, host):
> self.scheme = scheme
> self.host = host
>
>
> www_urlpatterns = [
> url(r'^$', images_views.photos, {'template': 'images/homepage.html'}, 
> name='homepage'),
> url(r'^users/', include('users.urls.profiles')),
> url(r'^blog/', include('writing.urls.content'), {'section_slug': 'blog'}),
> url(r'^galleries/', include('writing.urls.content'), {'section_slug': 
> 'galleries'}),
> url(r'^writers/', include('writing.urls.authors')),
> url(r'^', include('vendors.urls.www')),
> url(r'^', include('images.urls')),
> ] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
>
> my_urlpatterns = [
> url(r'^', include('users.urls.my')),
> url(r'^businesses/', include('vendors.urls.my')),
> url(r'^user/', include('users.urls.auth')),
> url(r'^user/', include('users.urls.social')),
> ]
>
> manage_urlpatterns = [
> url(r'^admin/', include(admin.site.urls)),
> ]
>
> payments_urlpatterns = [
> url(r'^braintree/', include('payments.urls.payments_braintree')),
> ]
>
> urlpatterns = [
> # non-logged in pages; public facing and indexable by search engines
> url(SchemeHostConstraint(*settings.SITE_DOMAIN_WWW), 
> include(www_urlpatterns)),
> # logged in users only, public facing and not indexable by search engines 
> (perhaps some exceptions...)
> 
>
> ...

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f7c7e16a-7c4d-4170-ba02-3325df52b06a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding "bits of entropy" argument to crypto.get_random_string

[Nick Timkovich]

By the presence of a "bits" measure in the documentation of the function it 
seems to be known that it's a measure of interest. The benefit of adding it 
into Django is that by review of others it can be assured to be correct and 
will reduce the likelihood of security-related bugs. A bit contrived, 
perhaps, but as adding such a parameter requires no external dependencies, 
the bar shouldn't be terribly high.

On Saturday, March 5, 2016 at 2:51:58 AM UTC-6, Moritz S. wrote:
>
> Can't you just define your own function called "get_random_string_entropy" 
> that 
> calculates the length and then calls get_random_string? 
> What would be the benefit of doing that in Django directly? 
>
> Am 05.03.2016 um 00:15 schrieb Nick Timkovich: 
> > Rather than guess at the appropriate string length to get some level of 
> > security, I'd like to add a (minimum) bits of entropy argument to 
> > get_random_string, so I could say something like 
> get_random_string(bits=256) and 
> > have it do the math for me: math.ceil(bits / 
> math.log2(len(allowed_chars))). 
> > 
> > Not sure what should happen if both bits and length are specified, let 
> bits 
> > override? ValueError? whichever is longer/more random/secure (maybe then 
> call it 
> > min_bits)? 
> > 
> > I seem to recycle that snippet in many of my projects, and I hope it 
> would be 
> > useful for others. 
>
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/373c2b74-de84-4bb0-93b8-38f9f3365b2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove old SVN branches from git repository?

[Tim Graham]

I see these branches are documented: 
https://docs.djangoproject.com/en/dev/internals/git/#feature-development-branches.
 
In reading that I saw the mention about a grafts file. I don't entirely 
understand what that does but when I was reading about it, I saw "As of Git 
1.6.5, the more flexible git replace 
 has been 
added." I don't know if that might allow deleting the branches? Anyway, if 
anyone wants to take some action here that's okay with me as I'm not really 
motivated to invest any more time than clicking "delete branch" which 
apparently isn't acceptable at this time.

On Wednesday, February 24, 2016 at 7:13:55 PM UTC-5, Markus Holtermann 
wrote:
>
> I'd like to keep them around somewhere. Even if it's just a wiki page 
> which links to the last commits of each branch. 
>
> When you have a local checkout of a brach that checkout is staying even 
> if the branch is removed on a remote. Also your local references to 
> remote branches are kept unless you call `git remote prune upstream`. 
> The branches in the remotes should still be available. 
>
> /Markus 
>
> On Wed, Feb 24, 2016 at 12:46:38PM -0800, Tim Graham wrote: 
> >They're already in everyone's forks too unless you delete them. Not sure 
> if 
> >deleting them from the main repo would delete them for all forks too. 
> > 
> >On Wednesday, February 24, 2016 at 3:36:53 PM UTC-5, Florian Apolloner 
> >wrote: 
> >> 
> >> 
> >> 
> >> On Wednesday, February 24, 2016 at 9:12:19 PM UTC+1, Shai Berger wrote: 
> >>> 
> >>> If they're a nuisance, I suggest that we clone the Django repo into 
> >>> another 
> >>> one under the django organization -- say, 
>  "django-historical-branches" 
> >>> -- 
> >>> before removing them from the main repo. 
> >>> 
> >> 
> >> I was about to suggest the same :D 
> >> 
> > 
> >-- 
> >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-develop...@googlegroups.com . 
> >To post to this group, send email to django-d...@googlegroups.com 
> . 
> >Visit this group at https://groups.google.com/group/django-developers. 
> >To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ffceaa3b-ae34-4d2f-8ea2-7fa382b94a30%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  (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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a631d527-bd54-4234-9148-ae519865bfe9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding "bits of entropy" argument to crypto.get_random_string

[Tim Graham]

My opinion is that django.utils needn't grow features that Django itself 
doesn't use.

On Monday, March 7, 2016 at 11:04:48 AM UTC-5, Nick Timkovich wrote:
>
> By the presence of a "bits" measure in the documentation of the function 
> it seems to be known that it's a measure of interest. The benefit of adding 
> it into Django is that by review of others it can be assured to be correct 
> and will reduce the likelihood of security-related bugs. A bit contrived, 
> perhaps, but as adding such a parameter requires no external dependencies, 
> the bar shouldn't be terribly high.
>
> On Saturday, March 5, 2016 at 2:51:58 AM UTC-6, Moritz S. wrote:
>>
>> Can't you just define your own function called 
>> "get_random_string_entropy" that 
>> calculates the length and then calls get_random_string? 
>> What would be the benefit of doing that in Django directly? 
>>
>> Am 05.03.2016 um 00:15 schrieb Nick Timkovich: 
>> > Rather than guess at the appropriate string length to get some level of 
>> > security, I'd like to add a (minimum) bits of entropy argument to 
>> > get_random_string, so I could say something like 
>> get_random_string(bits=256) and 
>> > have it do the math for me: math.ceil(bits / 
>> math.log2(len(allowed_chars))). 
>> > 
>> > Not sure what should happen if both bits and length are specified, let 
>> bits 
>> > override? ValueError? whichever is longer/more random/secure (maybe 
>> then call it 
>> > min_bits)? 
>> > 
>> > I seem to recycle that snippet in many of my projects, and I hope it 
>> would be 
>> > useful for others. 
>>
>>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/43f93e73-0119-4b2b-8df2-402c6a64064b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is there a reason these features cannot be added inside Django core?

[Tim Graham]

1. This has been raised before, but it seems there's not much interest. See 
also: 
https://groups.google.com/d/topic/django-developers/jsMlF6u4yxU/discussion

2. Here's a tentatively accepted ticket for editing OneToOne related models 
as inlines: https://code.djangoproject.com/ticket/21135

For future reference, it's probably better to raise one issue per thread so 
that you can use a subject line that corresponds to each feature.

On Tuesday, January 12, 2016 at 10:21:29 AM UTC-5, Luis Masuelli wrote:
>
> These features are pretty core-related.
>
> 1. Features from django-polymorphic. To mantain bw compatibility, the 
> hierarchy parent could need to add something like polymorphic=True in the 
> meta to this feature be activated.
> 2. Something like this snippet regarding Inlines in admin: 
> https://djangosnippets.org/snippets/2032/, to be able to do this:
>
> class A(models.Model):
>
> b = OneToOneField('B')
>
> class B(models.Model):
>
> ...
>
> class AInlineAdmin(StackedInline):
>
> model = A
>
> class BAdmin(ModelAdmin):
>
> inlines = (AInlineAdmin)
>
> site.register(B, BAdmin)
>
> Sometimes, doing this could be desirable as it was in my case.
>
> Additionally, I don't know if it is a feature or a bug, but when I see the 
> inline model section for a O2O field, the section is labeled as:
>
> (verbose_name_plural)
> (verbose_name) #1
>
> Example (the Customer model admin has an inline to ContactDetails; the 
> ContactDetails model has a direct O2O field to Customer; in this case I 
> didn't use the reverse inline snippet I posted above, but the standard 
> supported way):
>
> Contacts Details
> Contact Details #1
>
> Even when there is only one element (since it is a O2O). Could a change be 
> done for that case so these captions become...
>
> (verbose_name)
> (nothing)
>
> only for the O2O case? (both in the standard way and -if you decide to 
> support- the inverse inline)
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5b870fb3-957c-4b64-97a5-3ea0053f8b58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[James Pic]

Thanks Tim. Something like that would work, perhaps the first step
would be to make modelfield.formfield a bit more configurable ?

Currently, the default form field class for a model field is hardcoded
in the model field's formfield() method, ie:
https://github.com/django/django/blob/master/django/db/models/fields/related.py#L945

Changing this to an attribute allows to replace it in an
AppConfig.ready() method as such:

class TestApp(AppConfig):
name = 'select2_one_to_one'

def ready(self):
model = self.get_model('TestModel')
# Perhaps that's the kind of nice place to override this
kind of things
model._meta.get_field('test').formfield_defaults['widget']
= forms.RadioSelect
# django-autocomplete-light users would execute something like:
model._meta.get_field('test').formfield_defaults['widget']
= autocomplete.Select2(url='my_autocomplete_url')

This also allows to change it when defining the field:

class TestModel(models.Model):
name = models.CharField(max_length=200)

test = models.OneToOneField(
'self',
null=True,
blank=True,
related_name='related_test_models',
# This seems like it would always be useful
formfield_defaults={
'widget': forms.RadioSelect
}
)

I checked that this changed rendering in the admin, and it felt pretty
awesome I recon, to see my override in the default form and inline
model forms too.

Here's what the poc patch looks like for ForeignKey (3 additions and 1
deletion, works on OneToOne field too):

https://github.com/jpic/django/commit/d102f362f3c1ceaf2d5224d71f788c0821a481ae

Of course, that works when the model field already supports a form
field. It doesn't solve the problem with virtual fields that don't
have a formfield() method like GenericForeignKey, where an app would
like to be able to provide a formfield() as well as logic for
modelfield.{value_from_object,save_form_data}(). Perhaps that's
something we could deal with later *if* we decide to deal with it ?

Meanwhile, could we perhaps start working on a consistent way to
configure formfield() in Django ? That doesn't solve all the use cases
I mentioned, but perhaps it would be a nice step forward.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaeBNZwpwrY0QRisKNGdD98_0iJV2%3DNrH5Nzkd-892Xakw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Admin hstore widget

[Curtis Maloney]

On 08/03/16 02:43, Tim Graham wrote:

1. Merging something minimal always help to get feature requests. :-)





2. Could you be more specific about what you're looking for? All the
existing documentation for style related stuff is at
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/.
I also thought of ticket https://code.djangoproject.com/ticket/14831.


This is no way covers the HTML or CSS structures used in admin.

Given the deafening roar of absolutely no interest in this feature, I 
guess I'll drop it.


--
C

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/56DDF031.10803%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Meet Bhagdev]

Hi all,

On interacting with several Django developers and committers, one of the 
questions often came up, can I use SQL Server on non Window OS's? I wanted 
to share that today Microsoft announced SQL Server availibility on Linux - 
https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
. 

While there is still work needed to strengthen the MSSQL-Django story, we 
hope this aids more Linux developers to give SQL Server a shot. Let me know 
of your thoughts and questions :)

Cheers,
Meet

On Monday, February 22, 2016 at 4:54:38 PM UTC-8, Vin Yu wrote:
>
> Hey Folks, 
>
> My name is Vin and I work with Meet in the Microsoft SQL Server team. Just 
> wanted to let you all know we are still looking into how we can better 
> improve and support MSSQL for the Django framework. We’ll continue to sync 
> with Michael and let you know of any updates soon. 
>
> Christiano and Tim - thanks for sharing your interest and sharing how you 
> are using Django with MSSQL. It's great to learn from your scenarios. 
>
> If you have any concerns, questions or comments feel free to reach out to 
> me at vinsonyu[at]microsoft.com

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5b3a0092-57f1-45e4-a29b-9dc0eac4bebe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Admin hstore widget

[Josh Smeaton]

I wouldn't drop it if I were you. I (think) I watched you demo the hstore 
admin field at melbdjango and it looked cool to me. If I used hstorefield 
I'd be interested in the implementation. The dev ML isn't really indicative 
of the broader django community I feel, because only a small portion of the 
community seem to participate. Deafening silence here may still lead to 
cheers elsewhere once it's available. 

If I were you, I'd make a small screencast/gifv of the feature in action, 
reach out to some people that you know are using contrib.postgres (starting 
with Marc), and explicitly solicit their feedback on usefulness. If you 
still don't feel there is a real desire to have in core, could you release 
it as a 3rd party project? If it requires hooks in core to support custom 
fields then push those changes through separately.

My 2c :)

On Tuesday, 8 March 2016 08:18:59 UTC+11, Curtis Maloney wrote:
>
>
>
> On 08/03/16 02:43, Tim Graham wrote: 
> > 1. Merging something minimal always help to get feature requests. :-) 
>
>
>
> > 2. Could you be more specific about what you're looking for? All the 
> > existing documentation for style related stuff is at 
> > 
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/.
>  
>
> > I also thought of ticket https://code.djangoproject.com/ticket/14831. 
>
> This is no way covers the HTML or CSS structures used in admin. 
>
> Given the deafening roar of absolutely no interest in this feature, I 
> guess I'll drop it. 
>
> -- 
> C 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f6144212-cdde-4729-9d42-3d79397079ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Josh Smeaton]

Wow, that's really great news! I haven't used mssql for a number of years 
but it was always very nice to work with. Having it available to run on 
linux will make it much easier for the Django community to test against 
mssql, provided we're able to get/develop an appropriate driver and 
backend. 

Cheers

On Tuesday, 8 March 2016 09:37:06 UTC+11, Meet Bhagdev wrote:
>
> Hi all,
>
> On interacting with several Django developers and committers, one of the 
> questions often came up, can I use SQL Server on non Window OS's? I wanted 
> to share that today Microsoft announced SQL Server availibility on Linux - 
> https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
> . 
>
> While there is still work needed to strengthen the MSSQL-Django story, we 
> hope this aids more Linux developers to give SQL Server a shot. Let me know 
> of your thoughts and questions :)
>
> Cheers,
> Meet
>
> On Monday, February 22, 2016 at 4:54:38 PM UTC-8, Vin Yu wrote:
>>
>> Hey Folks, 
>>
>> My name is Vin and I work with Meet in the Microsoft SQL Server team. 
>> Just wanted to let you all know we are still looking into how we can better 
>> improve and support MSSQL for the Django framework. We’ll continue to sync 
>> with Michael and let you know of any updates soon. 
>>
>> Christiano and Tim - thanks for sharing your interest and sharing how you 
>> are using Django with MSSQL. It's great to learn from your scenarios. 
>>
>> If you have any concerns, questions or comments feel free to reach out to 
>> me at vinsonyu[at]microsoft.com
>
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e3f3a923-4a5a-406a-9ace-6afe81d9383f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.