Re: Proposal on Custom Indexes - Google Summer of Code

[Anssi Kääriäinen]

I was assuming that the Index class would be responsible for
generating the whole SQL. Seems like this isn't the case.

I assumed something like this would happen when a new index is added:
   1. User adds a new BTreeIndex to a model
   2. The makemigrations command detects a change and creates a
migration file with AddIndex operation
   3. The migrate command calls BTreeIndex.database_forwards, the
database_forwards method generates the needed SQL ('CREATE INDEX
foobar ON thetable(thecol)')
   4. The migration framework runs the generated SQL

This way would let the BTreeIndex class generate the full SQL.

If I am not mistaken, the plan is to generate the SQL mostly in the
migration operations, that is the user can't alter the full SQL by
creating custom Index classes. So, #3 above would be replaced by the
AddIndex operation detecting changes in the BTreeIndex class and
generating the needed SQL. The main point is that the AddIndex
operation isn't under user control, so parts of the generated SQL is
essentially hard-coded into Django.

Giving users full control over the generated SQL would allow contrib
or 3rd party apps to create fully custom index classes for their
needs. The expressions/transforms/lookups approach has shown this is a
powerful approach. As an example, it is unlikely we will add BRIN
index support to Django core, but it could be added to
django.contrib.postgres.

It is worth considering if we could allow users to have full control
of the generated SQL. It might be a bit too much for one GSoC program,
so I'm fine with a decision to use the hard-coded approach.

 - Anssi

On Sun, Mar 13, 2016 at 10:24 AM, akki  wrote:
>
>>
>> What about calling the attribute something like "constraints" similar to
>> how it's done in SQLAlchemy [1]? For now the attribute can just contain a
>> list of Index() instances but that would also lay grounds for supporting
>> check constraints and other related table level options.
>
> Since we are just allowing instances of Index class and it's subclasses
> right now, I don't think there is much gain in naming it "constraints". It
> might even confuse the user.
>
> --
> 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/090de3a1-63da-4897-9bb6-a7997a9b9610%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/CALMtK1Egv1R7XOA-bG9RPM4iRsCY88szCE7KPj%3Dzmq%3DGFJeBGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[Anssi Kääriäinen]

On Thu, Mar 10, 2016 at 8:17 AM, Markus Holtermann
 wrote:
> Hi Akshesh,
>
> thank you for your proposal! Sounds like a good plan.
>
> On Thursday, March 10, 2016 at 8:16:10 AM UTC+11, akki wrote:
>
>>> Once the index is added to a model, the model can inject itself into the
>>> index, or the schema editor can use the originating model to get data it
>>> needs. No need to pass the model into the index type I think. Regarding the
>>> name, I'm unsure if I prefer a name=Index() or an Index(name='') approach.
>>> It'd be good to see that choice in your proposal with a couple of pros and
>>> cons.
>>
>>
>> Well, since we are defining these indexes in a list (to be stored in
>> Meta.indexes) I would go with the Index(name='') approach.
>
>
> I'd prefer the Index(name='') approach
>
> class MyModel(models.Model):
> field1 = models.CharField()
> field2 = models.CharField()
>
> class Meta:
> indexes = [
> Index('field1', 'field2', name='some_index_across_two_columns'),
> 'field2',  # Would be the same as Index('field2'), an index on
> this one column -- name derived from field name: field2_index
> Index(ToLower('field1')),  # A functional index on field1 --
> name derived from field name and functions: field1_tolower_index
> ]
>
> That way you should also be able to check for duplicate index names.

How about

class MyModel(models.Model):
field1 = models.CharField()
field2 = models.CharField()

field1_idx = models.Index('field1')
field2_lower_idx = models.Index(ToLower('field2'))

The main advantage is that the same syntax can be used for custom
indexes, constraints, composite fields and so on. Internally we could
of course have the same representation for indexes as before.

 - Anssi

-- 
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/CALMtK1Eet%3DzPTKXJJpuRy8b0tWF%2BaA9-QaT%2BzfF%3DGV6wAd3N3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

Hi

I have updated my proposal 
 and completed the 
timeline. I saw how expressions work and now have a clear idea of how they 
would be used in indexes - I have added a short description of the same in 
my proposal.

Please have a look. I would love to hear any suggestions for further 
improvement. If there are any questions, I will be happy to answer.

Regards
Akshesh Doshi
(akki)

-- 
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/5ebdb9b6-5406-40b1-a18f-ede8851192c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django startproject template enhancement proposal

[aRkadeFR]

FMPOV, the default template from Django influences:
- the use of settings in .py files over the environment variables;
- the use of manage.py over django-admin command;
- the merge of the "core application" and the project (settings/wsgi...) 
in one django app;


This is very personal and based on my experience while learning Django.

On 03/12/2016 09:01 PM, Florian Apolloner wrote:

On Saturday, March 12, 2016 at 5:29:55 PM UTC+1, is_null wrote:

I know it's too opinionated to add that to django, but I'd like to
open a discussion here and perhaps there's something we might find
worth changing in django's default project template.


Imo it should stay as minimal as it is currently. Since we do allow 
you to specify --template to startproject, you can prepare a default 
project layout that suits you.

--
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/95a6a70e-0499-456d-8dfe-326032710a64%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/56E669E9.5030101%40arkade.info.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

Hi Annsi

Yes, the AddIndex operation would detect the changes and the user would not 
have full control over the generated SQL.

I don't know if it would be a good idea to mix index definitions with 
fields while creating models. Users have traditionally been defining fields 
that way and indexes feel more like a "Meta" property to me. Constraints 
can also be added to Meta (maybe merged together with indexes) whenever 
they arrive, but I don't how soon they will be included.

Regards
Akshesh Doshi
(akki)

On Monday, 14 March 2016 12:53:30 UTC+5:30, Anssi Kääriäinen wrote:
>
> On Thu, Mar 10, 2016 at 8:17 AM, Markus Holtermann 
>  wrote: 
> > Hi Akshesh, 
> > 
> > thank you for your proposal! Sounds like a good plan. 
> > 
> > On Thursday, March 10, 2016 at 8:16:10 AM UTC+11, akki wrote: 
> > 
> >>> Once the index is added to a model, the model can inject itself into 
> the 
> >>> index, or the schema editor can use the originating model to get data 
> it 
> >>> needs. No need to pass the model into the index type I think. 
> Regarding the 
> >>> name, I'm unsure if I prefer a name=Index() or an Index(name='') 
> approach. 
> >>> It'd be good to see that choice in your proposal with a couple of pros 
> and 
> >>> cons. 
> >> 
> >> 
> >> Well, since we are defining these indexes in a list (to be stored in 
> >> Meta.indexes) I would go with the Index(name='') approach. 
> > 
> > 
> > I'd prefer the Index(name='') approach 
> > 
> > class MyModel(models.Model): 
> > field1 = models.CharField() 
> > field2 = models.CharField() 
> > 
> > class Meta: 
> > indexes = [ 
> > Index('field1', 'field2', 
> name='some_index_across_two_columns'), 
> > 'field2',  # Would be the same as Index('field2'), an index 
> on 
> > this one column -- name derived from field name: field2_index 
> > Index(ToLower('field1')),  # A functional index on field1 -- 
> > name derived from field name and functions: field1_tolower_index 
> > ] 
> > 
> > That way you should also be able to check for duplicate index names. 
>
> How about 
>
> class MyModel(models.Model): 
> field1 = models.CharField() 
> field2 = models.CharField() 
>
> field1_idx = models.Index('field1') 
> field2_lower_idx = models.Index(ToLower('field2')) 
>
> The main advantage is that the same syntax can be used for custom 
> indexes, constraints, composite fields and so on. Internally we could 
> of course have the same representation for indexes as before. 
>
>  - Anssi 
>

-- 
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/f07f1303-fd25-43b9-b50f-353da0c69ad3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[Michal Petrucha]

On Mon, Mar 14, 2016 at 12:45:09AM -0700, akki wrote:
> Hi Annsi
> 
> Yes, the AddIndex operation would detect the changes and the user would not 
> have full control over the generated SQL.
> 
> I don't know if it would be a good idea to mix index definitions with 
> fields while creating models. Users have traditionally been defining fields 
> that way and indexes feel more like a "Meta" property to me. Constraints 
> can also be added to Meta (maybe merged together with indexes) whenever 
> they arrive, but I don't how soon they will be included.

The way I see it, the question is: how well can we maintain this
distinction (column-backed fields in the model class itself, vs.
non-field constructs in Meta). Right now the boundary between the two
is more or less clear, with a few exceptions (ManyToManyField and
GenericForeignKey, for instance). Once we grow support for
CompositeFields, that will be another construct which looks kind of
like a limited field from one angle, but actually resembles non-field
constructs in a SQL table, too. If I ever manage to dust off and push
through my ForeignKey refactor, even ForeignKey would become this kind
of virtual construct -- just a named SQL constraint with some
Python-level behavior tacked on top of it.

To be honest, personally, I kind of like SQLAlchemy's approach, which
simply puts all table-level constructs (columns, constraints, indexes)
into model classes at the same level. It does not leave room for this
kind of subjective bikeshedding.

Cheers,

Michal

-- 
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/20160314084424.GO25061%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Proposal on Custom Indexes - Google Summer of Code

[Marc Tamlyn]

I like this a lot. Even we we then keep the "Meta" options as they are
forever, they then become shortcuts to what you could define explicitly.

In any case, we would need some careful checks that (for example) you can't
have identical indexes defined in multiple ways with the same names.

On 14 March 2016 at 07:23, Anssi Kääriäinen  wrote:

> On Thu, Mar 10, 2016 at 8:17 AM, Markus Holtermann
>  wrote:
> > Hi Akshesh,
> >
> > thank you for your proposal! Sounds like a good plan.
> >
> > On Thursday, March 10, 2016 at 8:16:10 AM UTC+11, akki wrote:
> >
> >>> Once the index is added to a model, the model can inject itself into
> the
> >>> index, or the schema editor can use the originating model to get data
> it
> >>> needs. No need to pass the model into the index type I think.
> Regarding the
> >>> name, I'm unsure if I prefer a name=Index() or an Index(name='')
> approach.
> >>> It'd be good to see that choice in your proposal with a couple of pros
> and
> >>> cons.
> >>
> >>
> >> Well, since we are defining these indexes in a list (to be stored in
> >> Meta.indexes) I would go with the Index(name='') approach.
> >
> >
> > I'd prefer the Index(name='') approach
> >
> > class MyModel(models.Model):
> > field1 = models.CharField()
> > field2 = models.CharField()
> >
> > class Meta:
> > indexes = [
> > Index('field1', 'field2',
> name='some_index_across_two_columns'),
> > 'field2',  # Would be the same as Index('field2'), an index
> on
> > this one column -- name derived from field name: field2_index
> > Index(ToLower('field1')),  # A functional index on field1 --
> > name derived from field name and functions: field1_tolower_index
> > ]
> >
> > That way you should also be able to check for duplicate index names.
>
> How about
>
> class MyModel(models.Model):
> field1 = models.CharField()
> field2 = models.CharField()
>
> field1_idx = models.Index('field1')
> field2_lower_idx = models.Index(ToLower('field2'))
>
> The main advantage is that the same syntax can be used for custom
> indexes, constraints, composite fields and so on. Internally we could
> of course have the same representation for indexes as before.
>
>  - Anssi
>
> --
> 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/CALMtK1Eet%3DzPTKXJJpuRy8b0tWF%2BaA9-QaT%2BzfF%3DGV6wAd3N3g%40mail.gmail.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/CAMwjO1GG-TXEGfpBYnRb9QEum2Gjmxm_BkO%2BNtoLWUCYAm0w2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

>
>
> you can't have identical indexes defined in multiple ways with the same 
> names.
>
 
Yes, I will be checking for the duplications at the autodetector level 
itself. We need to take care that no two indexes are for the same fields, 
and none of them have a clashing name. On such an occurrence, we can raise 
an error like "Multiple indexes have been set for 'field1' " or merge them 
ourself internally (if they mean exactly the same).

-- 
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/6a0c0ef6-1664-45d9-88d0-8e9532c5efd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django startproject template enhancement proposal

[James Pic]

That sounds pretty fair, particularly since the new default settings
provide a great ootb experience.

Thanks for your feedback, keep up the great work !

-- 
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/CALC3Kaf5QrgufVaUcZngD5oCDbV0sKm6Jr_Pa2hOQen2BgQZwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

MySQL data loss possibility with concurrent ManyToManyField saves

[Tim Graham]

Could some MySQL users take a look at ticket #26347 [0] and recommend how 
to proceed? I think it's probably not a new issue but I'm a bit surprised 
it hasn't come up before if so.

[0] https://code.djangoproject.com/ticket/26347

-- 
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/286b0efb-673f-42d7-a1f3-5de76fc039c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: TransactionManagementError is raised when autocommit …

[Tore Lundqvist]

I recently upgrade Django 1.7->1.8 and ended up needing to patch 
set_rollback()  and comment out the "exception if not in an atomic block" 
part. The problem was that sometimes database errors like IntegrityError 
occurred because multiple workers was trying to create the same data but 
that's ok, the code captures the error and does a get instead of a create 
and moves on. A rollback was not an option here as that wound roll back a 
lot of other things that was ok. Way do you need to be in a atomic block to 
use this function? Is the filosofi of Djangos transaction handling that an 
exception from the database should always be handled with a rollback no 
matter what?

Cheers
Tore

-- 
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/a8daaa98-f66a-40e5-bb4d-c0d4ad647f70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: TransactionManagementError is raised when autocommit …

[Jeremy Dunck]

You can use atomic just over the section that causes the error.  The issue
is that different db engines have different semantics under error during
transaction. Rolling back to the last savepoint (as atomic does when
nested) recovers the ability to complete the remainder of the transaction.
With a savepoint to roll back to, in some DBs, the full transaction is lost.
On Mar 14, 2016 11:09 AM, "Tore Lundqvist"  wrote:

> I recently upgrade Django 1.7->1.8 and ended up needing to patch
> set_rollback()  and comment out the "exception if not in an atomic block"
> part. The problem was that sometimes database errors like IntegrityError
> occurred because multiple workers was trying to create the same data but
> that's ok, the code captures the error and does a get instead of a create
> and moves on. A rollback was not an option here as that wound roll back a
> lot of other things that was ok. Way do you need to be in a atomic block to
> use this function? Is the filosofi of Djangos transaction handling that an
> exception from the database should always be handled with a rollback no
> matter what?
>
> Cheers
> Tore
>
> --
> 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/a8daaa98-f66a-40e5-bb4d-c0d4ad647f70%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/CAM0i3f4i5qi%3DHH%2B4kU8Kh%3D2kTgprCUNHQEWW4EmvYwpNV4hRKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[James Bennett]

Personally I've long been in favor of drastically simplifying the email
regex and essentially telling people that if they want to support
triply-nested comments in a bang-path address they can write their own :)

Is there an actual compelling reason to not just pare it down to "word
characters and/or some punctuation, followed by an @, followed by some more
word characters and/or punctuation"?

On Mon, Mar 14, 2016 at 11:09 AM, Tim Graham  wrote:

> On a pull request that proposes to tighten the validation of
> EmailValidator [0], Ned Batchelder questioned the usefulness of this:
>
> "Can I respectfully suggest that continuing to tweak this complex regex to
> get asymptotically closer to perfection is not worth it? Especially to fix
> false positives. What real-world problem is happening because "gmail.-com"
> is accepted? "gmail.ccomm" is also accepted, but is just as useless as an
> email address."
>
> Collin Anderson proposed:
>
> "I think we should try to just match the standard html  type="email"> validation. I'd imagine that most uses cases would want to
> match that. We might be able to use the regex verbatim from the standard
> itself:
>
> ​
> https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email
> )
> If people want to allow things outside of that they could use a custom
> regex.
> Though it gets more complicated when considering Unicode. Unicode needs to
> get normalized to ascii before running through the official regex."
>
> (Of course, this may be somewhat backwards-incompatible.)
>
> What are your thoughts on this? I don't mind putting a halt to
> enhancements to the validation as long as we can articulate a sensible
> policy in the documentation.
>
> [0] https://github.com/django/django/pull/5612
>
> --
> 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/eb04034e-ea07-489f-aaf9-a08a5d241c4b%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/CAL13Cg8L6Gduwv4n%2BD68YqjEOmE1KWCKPPGnXjQr%2BR6a1HSSsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

How to extend admin/user to adapt it to my business problem

[iherrera]

I have to save other information of users but i want to use the users  
that are created in the admin in django how can i do that ?? i am  
sorry if this is a basic question but i am a beginner in django



--
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/20160314131546.Horde.upxUMVOsJu1W5vHCrW02kPA%40webmail.nauta.cu.
For more options, visit https://groups.google.com/d/optout.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Michael Manfre]

Simple is better. Anyone who needs/wants something more complex is not
prevented by Django from doing so.

Regards,
Michael Manfre

On Mon, Mar 14, 2016 at 2:31 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Indeed, for some reason, the URL and email validators get anywhere from 2
> to 8 changes in every Django version, and there’s no end in sight. (I
> contributed to this. Sorry.)
>
> Like James, I’m in favor of making the validation much more simple and
> documenting it. This seems better than perpetually modifying it at the risk
> of introducing regressions.
>
> --
> Aymeric.
>
> On 14 Mar 2016, at 19:17, James Bennett  wrote:
>
> Personally I've long been in favor of drastically simplifying the email
> regex and essentially telling people that if they want to support
> triply-nested comments in a bang-path address they can write their own :)
>
> Is there an actual compelling reason to not just pare it down to "word
> characters and/or some punctuation, followed by an @, followed by some more
> word characters and/or punctuation"?
>
> On Mon, Mar 14, 2016 at 11:09 AM, Tim Graham  wrote:
>
>> On a pull request that proposes to tighten the validation of
>> EmailValidator [0], Ned Batchelder questioned the usefulness of this:
>>
>> "Can I respectfully suggest that continuing to tweak this complex regex
>> to get asymptotically closer to perfection is not worth it? Especially to
>> fix false positives. What real-world problem is happening because
>> "gmail.-com" is accepted? "gmail.ccomm" is also accepted, but is just as
>> useless as an email address."
>>
>> Collin Anderson proposed:
>>
>> "I think we should try to just match the standard html > type="email"> validation. I'd imagine that most uses cases would want to
>> match that. We might be able to use the regex verbatim from the standard
>> itself:
>>
>> ​
>> https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email
>> )
>> If people want to allow things outside of that they could use a custom
>> regex.
>> Though it gets more complicated when considering Unicode. Unicode needs
>> to get normalized to ascii before running through the official regex."
>>
>> (Of course, this may be somewhat backwards-incompatible.)
>>
>> What are your thoughts on this? I don't mind putting a halt to
>> enhancements to the validation as long as we can articulate a sensible
>> policy in the documentation.
>>
>> [0] https://github.com/django/django/pull/5612
>>
>> --
>> 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/eb04034e-ea07-489f-aaf9-a08a5d241c4b%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/CAL13Cg8L6Gduwv4n%2BD68YqjEOmE1KWCKPPGnXjQr%2BR6a1HSSsA%40mail.gmail.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/EB89DAC8-7D6F-4A9E-B3F2-476E6EE1F377%40polytechnique.org
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are 

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Florian Apolloner]

On Monday, March 14, 2016 at 8:08:09 PM UTC+1, Michael Manfre wrote:
>
> Simple is better. Anyone who needs/wants something more complex is not 
> prevented by Django from doing so.
>

+1 to that and what the rest said ;) 

>
> Regards,
> Michael Manfre
>
> On Mon, Mar 14, 2016 at 2:31 PM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> Indeed, for some reason, the URL and email validators get anywhere from 2 
>> to 8 changes in every Django version, and there’s no end in sight. (I 
>> contributed to this. Sorry.)
>>
>> Like James, I’m in favor of making the validation much more simple and 
>> documenting it. This seems better than perpetually modifying it at the risk 
>> of introducing regressions.
>>
>> -- 
>> Aymeric.
>>
>> On 14 Mar 2016, at 19:17, James Bennett  
>> wrote:
>>
>> Personally I've long been in favor of drastically simplifying the email 
>> regex and essentially telling people that if they want to support 
>> triply-nested comments in a bang-path address they can write their own :)
>>
>> Is there an actual compelling reason to not just pare it down to "word 
>> characters and/or some punctuation, followed by an @, followed by some more 
>> word characters and/or punctuation"?
>>
>> On Mon, Mar 14, 2016 at 11:09 AM, Tim Graham > > wrote:
>>
>>> On a pull request that proposes to tighten the validation of 
>>> EmailValidator [0], Ned Batchelder questioned the usefulness of this:
>>>
>>> "Can I respectfully suggest that continuing to tweak this complex regex 
>>> to get asymptotically closer to perfection is not worth it? Especially to 
>>> fix false positives. What real-world problem is happening because 
>>> "gmail.-com" is accepted? "gmail.ccomm" is also accepted, but is just as 
>>> useless as an email address."
>>>
>>> Collin Anderson proposed:
>>>
>>> "I think we should try to just match the standard html >> type="email"> validation. I'd imagine that most uses cases would want to 
>>> match that. We might be able to use the regex verbatim from the standard 
>>> itself:
>>>
>>> ​
>>> https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email
>>> )
>>> If people want to allow things outside of that they could use a custom 
>>> regex.
>>> Though it gets more complicated when considering Unicode. Unicode needs 
>>> to get normalized to ascii before running through the official regex."
>>>
>>> (Of course, this may be somewhat backwards-incompatible.)
>>>
>>> What are your thoughts on this? I don't mind putting a halt to 
>>> enhancements to the validation as long as we can articulate a sensible 
>>> policy in the documentation.
>>>
>>> [0] https://github.com/django/django/pull/5612
>>>
>>> -- 
>>> 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/eb04034e-ea07-489f-aaf9-a08a5d241c4b%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-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/CAL13Cg8L6Gduwv4n%2BD68YqjEOmE1KWCKPPGnXjQr%2BR6a1HSSsA%40mail.gmail.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-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/EB89DAC8-7D6F-4A9E-B3F2-476E6EE1F377%40polytechnique.org
>>  
>> 

Re: Translate permission Django

[Collin Anderson]

Maybe we could have __str__ run the text through _()? I don't do much
translating.

On Mon, Mar 7, 2016 at 10:21 AM, Tim Graham  wrote:

> This has been discussed in several tickets (
> https://www.google.com/search?=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.
>

-- 
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/CAFO84S52fbNggXAHaQs5VAc8mCttaqwFEJpFCyVRsOEC6RgMrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Translate permission Django

[Florian Apolloner]

On Monday, March 14, 2016 at 9:24:30 PM UTC+1, Collin Anderson wrote:
>
> Maybe we could have __str__ run the text through _()? I don't do much 
> translating.
>

Wouldn't work since you'd still need the static strings for the po files 
somewhere. 

-- 
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/4fe7d204-f0f6-44dc-96f7-30620682b4e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MySQL data loss possibility with concurrent ManyToManyField saves

[Cristiano Coelho]

The django-admin interface is quite bad at handling concurrent 
modifications, this is one problem that might not happen on other backends 
and is quite critical, but other issues (that ain't critical like data loss 
but might cause unexpected errors) like two people viewing a model with 
some inline relations, one of them deletes one of the inline rows, the 
other one performs a save, it will try to re-save the one that's actually 
deleted and you end up with a "please correct the errors below" but you 
actually see no errors (because the row you tried to save no longer exists 
and is no longer loaded). Similar errors happen with other kind of 
concurrent modifications.

As of the MySQL issue, using a higher isolation level might fix the issue 
but I would strongly recommend not changing it as this is mainly an issue 
of how django performs the many-to-many save and not MySQL's fault at all. 
If you still go this path, it would be a good idea to have the isolation 
level change not set globally (on settings) but have it as an argument to 
the transaction.atomic() function to be able to change it per transaction.

Would it work if rather than performing a DELETE, SELECT, INSERT combo, you 
perform a DELETE and INSERT IGNORE ? I believe it is supported by MySQL and 
PostgreSQL has a similar functionallity starting on 9.5 but can be emulated 
through locks or nested queries.

What if there could be a way to store the last modified date of an object 
(check it's history maybe?), save that date locally on the admin form, and 
when performing the actual save compare those two and prompt an error if 
they do not match, that would prevent most concurrent modification issues 
(although make it a bit more anoying for edits that usually do not have any 
issue), although you might still be prone to a small race condition on the 
modification date, unless yo uperform a select for update on it first.



El lunes, 14 de marzo de 2016, 12:15:31 (UTC-3), Tim Graham escribió:
>
> Could some MySQL users take a look at ticket #26347 [0] and recommend how 
> to proceed? I think it's probably not a new issue but I'm a bit surprised 
> it hasn't come up before if so.
>
> [0] https://code.djangoproject.com/ticket/26347
>

-- 
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/01264edf-73db-4533-8210-bc35448029a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MySQL data loss possibility with concurrent ManyToManyField saves

[Shai Berger]

Hi,

I just commented on the ticket, but wanted to clarify a few things here:

On Tuesday 15 March 2016 00:48:02 Cristiano Coelho wrote:
> The django-admin interface is quite bad at handling concurrent
> modifications, this is one problem that might not happen on other backends
> and is quite critical, but other issues (that ain't critical like data loss
> but might cause unexpected errors) like two people viewing a model with
> some inline relations, one of them deletes one of the inline rows, the
> other one performs a save, it will try to re-save the one that's actually
> deleted and you end up with a "please correct the errors below" but you
> actually see no errors (because the row you tried to save no longer exists
> and is no longer loaded). Similar errors happen with other kind of
> concurrent modifications.

Right.
 
> As of the MySQL issue, using a higher isolation level might fix the issue

For the record, the suggestion made was to use a *lower* isolation level, to 
prevent the failure of transactions; I disagree with that recommendation, as 
it "prevents" the failure by enabling the kinds of data corruption you 
described above.

> but I would strongly recommend not changing it as this is mainly an issue
> of how django performs the many-to-many save and not MySQL's fault at all.

... and there I completely disagree. Django handles the updates in a 
transaction; first it deletes records, then (if they don't exist) writes them. 
The MySql docs explain that records are "snapshotted" at the beginning of the 
transaction, and so may actually be stale later on in it -- but that does not 
hold when the changes to the records are done *in* the transaction.
I asked the ticket's OP to describe a scenario where this is anything but a 
severe MySql bug, and I ask the same of you.

Shai.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Josh Smeaton]

+1. I don't think we need strict email validation. "looks vaguely like an 
email address" is enough for validation purposes in forms. Are there any 
security concerns we need to be aware of though?

On Tuesday, 15 March 2016 05:17:15 UTC+11, James Bennett wrote:
>
> Personally I've long been in favor of drastically simplifying the email 
> regex and essentially telling people that if they want to support 
> triply-nested comments in a bang-path address they can write their own :)
>
> Is there an actual compelling reason to not just pare it down to "word 
> characters and/or some punctuation, followed by an @, followed by some more 
> word characters and/or punctuation"?
>
>

-- 
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/0eaee2f1-f7a4-4003-8dfa-43bff467a837%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Translate permission Django

[Ramez Ashraf]

Hello, 

I created a 3rd party app for this issue , which will also display the app 
and model verbose names + display permissions in a tabular format for more 
easy setting when you have dozens of models.
Check it out at https://github.com/RamezIssac/django-tabular-permissions

Hope it helps :-)

Best

On Monday, February 29, 2016 at 11:20:36 AM UTC+2, Marcos Serrano wrote:
>
> 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/5af65811-b751-467c-9fcd-60e625a8b6b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Florian Apolloner]

On Tuesday, March 15, 2016 at 12:29:42 AM UTC+1, Josh Smeaton wrote:
>
> +1. I don't think we need strict email validation. "looks vaguely like an 
> email address" is enough for validation purposes in forms. Are there any 
> security concerns we need to be aware of though?
>

Absolutely, the crazier the regex, the more likely the chance of 
catastrophic backtracing. And emails are usually confirmed by sending an 
email anyways, everything else is not useful anyways -- validation is ment 
to prevent (some) stupid typos imo, not more.

-- 
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/44e113b6-36d0-4166-b5de-6dca0d83577c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django startproject template enhancement proposal

[Curtis Maloney]

Well, you could use:

mkdir my_client_name
django-admin startproject project my_client_name/

So it will create my_client_name/project/settings.py, and leave the 
namespace clear for you to create my_client_name/my_client_name/ as your 
app...


--
Curtis


On 15/03/16 10:51, Ramez Ashraf wrote:

May i add to the proposal suffixing the project_name inner directory
(the one containing settings.py) with '_proj'
Usually i start project called 'my_client_name', then i want an app
called 'my_client_name' too,
usually i do NOT want my main app called "my_client_name_app"..  table
names just looks ugly and unnecessarily long in this case.
Nor i want my main/parent directory to be called "my_client_name_proj" ,
unnecessarily long for nginx/uwsgi/other paths.


tl;dr
project_name/
   ..
   project_name+ "_proj"/
   app1/
   ..

Regards;



On Saturday, March 12, 2016 at 6:29:55 PM UTC+2, is_null wrote:

Hi all,

There's a pattern I like to use in my projects which I'd like to
suggest for django startproject.

It looks like:

project_name/
   setup.py
   src/
 myapp1/
 myapp2/
 project_name/
   settings.py
   urls.py
   manage.py
   wsgi.py

My settings.py here uses environment variables for everything to
override defaults.

Setup.py here allows:

- Adding an entry point,
- Installing all apps as packages,
- Installing test dependencies with extra_requires and pip install
project_name[test],
- Adding runtime dependencies.

For example, with that:

 entry_points = {
 'console_scripts': [
 'project_name = project_name.manage:main',
 ],
 },

And such a manage.py:

   def main():
 os.environ.setdefault("DJANGO_SETTINGS_MODULE",
"project_name.settings")
 from django.core.management import execute_from_command_line
 execute_from_command_line(sys.argv)

   if __name__ == "__main__":
 main()

Installing the package will add the project_name command, allowing to
run `project_name migrate` for example from any directory.

I know it's too opinionated to add that to django, but I'd like to
open a discussion here and perhaps there's something we might find
worth changing in django's default project template.

Thanks for reading !

--
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/de495e35-ecad-409c-a5d2-f30512c36931%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/56E756BF.905%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: MySQL data loss possibility with concurrent ManyToManyField saves

[Cristiano Coelho]

I can't tell if it is a bug on MySQL or not, but I did understand the same 
as you (the first example with Session A and Session B makes it more clear) 
so I can't quite understand how did the poster get that issue. I would like 
a similar example as the one in the docs, but with a delete in the middle, 
it is a bit unclear what happens, could a delete in the middle create a new 
"snapshot" for your next select?


So assuming the issue is real and not a bug in MySQL:

- Would a DELETE + INSERT IGNORE fix the issue, while also improving 
many-to-many updates to backends that support INSERT IGNORE? (one less 
select)

- Would a different isolation level help? What about SERIALIZABLE? In order 
to do this, the only good way to do this is to have the option to change 
serialization level on each transaction, improving the transaction.atomic() 
method so we do not affect other db operations changing the isolation level 
globally.

- Force a lock to the many-to-many updates (using select for update maybe?) 
?

- Use the object history to perform date matching and detect concurrent 
modifications of the same object before we do them and raise an error?


El lunes, 14 de marzo de 2016, 20:12:29 (UTC-3), Shai Berger escribió:
>
> Hi, 
>
> I just commented on the ticket, but wanted to clarify a few things here: 
>
> On Tuesday 15 March 2016 00:48:02 Cristiano Coelho wrote: 
> > The django-admin interface is quite bad at handling concurrent 
> > modifications, this is one problem that might not happen on other 
> backends 
> > and is quite critical, but other issues (that ain't critical like data 
> loss 
> > but might cause unexpected errors) like two people viewing a model with 
> > some inline relations, one of them deletes one of the inline rows, the 
> > other one performs a save, it will try to re-save the one that's 
> actually 
> > deleted and you end up with a "please correct the errors below" but you 
> > actually see no errors (because the row you tried to save no longer 
> exists 
> > and is no longer loaded). Similar errors happen with other kind of 
> > concurrent modifications. 
>
> Right. 
>   
> > As of the MySQL issue, using a higher isolation level might fix the 
> issue 
>
> For the record, the suggestion made was to use a *lower* isolation level, 
> to 
> prevent the failure of transactions; I disagree with that recommendation, 
> as 
> it "prevents" the failure by enabling the kinds of data corruption you 
> described above. 
>
> > but I would strongly recommend not changing it as this is mainly an 
> issue 
> > of how django performs the many-to-many save and not MySQL's fault at 
> all. 
>
> ... and there I completely disagree. Django handles the updates in a 
> transaction; first it deletes records, then (if they don't exist) writes 
> them. 
> The MySql docs explain that records are "snapshotted" at the beginning of 
> the 
> transaction, and so may actually be stale later on in it -- but that does 
> not 
> hold when the changes to the records are done *in* the transaction. 
> I asked the ticket's OP to describe a scenario where this is anything but 
> a 
> severe MySql bug, and I ask the same of you. 
>
> Shai. 
>

-- 
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/1df2641a-cdd9-49b9-b3fa-56dbe707fd8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django startproject template enhancement proposal

[Ramez Ashraf]

That's a solution :-) Thanks!
I personally create my projects/apps via a script with customized templates.

But for new comers, they will suffer from adding "_app" to their main app.
I know i did at one point.:-)

All the best.


On Tue, Mar 15, 2016 at 2:26 AM, Curtis Maloney  wrote:

> Well, you could use:
>
> mkdir my_client_name
> django-admin startproject project my_client_name/
>
> So it will create my_client_name/project/settings.py, and leave the
> namespace clear for you to create my_client_name/my_client_name/ as your
> app...
>
> --
> Curtis
>
>
>
> On 15/03/16 10:51, Ramez Ashraf wrote:
>
>> May i add to the proposal suffixing the project_name inner directory
>> (the one containing settings.py) with '_proj'
>> Usually i start project called 'my_client_name', then i want an app
>> called 'my_client_name' too,
>> usually i do NOT want my main app called "my_client_name_app"..  table
>> names just looks ugly and unnecessarily long in this case.
>> Nor i want my main/parent directory to be called "my_client_name_proj" ,
>> unnecessarily long for nginx/uwsgi/other paths.
>>
>>
>> tl;dr
>> project_name/
>>..
>>project_name+ "_proj"/
>>app1/
>>..
>>
>> Regards;
>>
>>
>>
>> On Saturday, March 12, 2016 at 6:29:55 PM UTC+2, is_null wrote:
>>
>> Hi all,
>>
>> There's a pattern I like to use in my projects which I'd like to
>> suggest for django startproject.
>>
>> It looks like:
>>
>> project_name/
>>setup.py
>>src/
>>  myapp1/
>>  myapp2/
>>  project_name/
>>settings.py
>>urls.py
>>manage.py
>>wsgi.py
>>
>> My settings.py here uses environment variables for everything to
>> override defaults.
>>
>> Setup.py here allows:
>>
>> - Adding an entry point,
>> - Installing all apps as packages,
>> - Installing test dependencies with extra_requires and pip install
>> project_name[test],
>> - Adding runtime dependencies.
>>
>> For example, with that:
>>
>>  entry_points = {
>>  'console_scripts': [
>>  'project_name = project_name.manage:main',
>>  ],
>>  },
>>
>> And such a manage.py:
>>
>>def main():
>>  os.environ.setdefault("DJANGO_SETTINGS_MODULE",
>> "project_name.settings")
>>  from django.core.management import execute_from_command_line
>>  execute_from_command_line(sys.argv)
>>
>>if __name__ == "__main__":
>>  main()
>>
>> Installing the package will add the project_name command, allowing to
>> run `project_name migrate` for example from any directory.
>>
>> I know it's too opinionated to add that to django, but I'd like to
>> open a discussion here and perhaps there's something we might find
>> worth changing in django's default project template.
>>
>> Thanks for reading !
>>
>> --
>> 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/de495e35-ecad-409c-a5d2-f30512c36931%40googlegroups.com
>> <
>> https://groups.google.com/d/msgid/django-developers/de495e35-ecad-409c-a5d2-f30512c36931%40googlegroups.com?utm_medium=email_source=footer
>> >.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/X1exTiEybMA/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/56E756BF.905%40tinbrain.net
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 

*Ramez AshrafCo-Founder and lead developer radev.io *

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

Re: thinking about the admin's scope and its description in the docs

[Ramez Ashraf]

Like what is "site front end" that the admin shouldn't replace ?!
I work with business application where clients puts data in and get reports 
back... (Like Sales/Store/Client balances and stuff)
I tried to work "my front end" (after getting the bad/wrong message from 
the docs) but it was so much time and mess and so much like re-inventing 
the wheel really.

The admin have lots of capabilities that does not yet exist in any other 
parts or CBV
To name a few:
1. Inlines  (FormView is like a teenager playing in the park next to 
Spartan Hero)
2. Entry Log change message 
3. Various 3rd party support (ex: django-reversion)
4. Changelist filters / search / table sort
5. Change form (save,save and continue, save and add another)
6. Delete confirmation displaying related objects that will get deleted 
along (though sometimes big and heavy)
.. the list can easily get much bigger.

And now with custom admin sites, we can get rid of the is_staff check, get 
rid of unrelated 3rd party app registered models (which might be only 
visible to staff indeed), override the templates and have a completely new 
look .

I think the admin should be seen as the "Best django-inc" way to manipulate 
data to your database, and get advertised as such.
Not "intended to use by only management", but to anyone with access to 
add/change/delete to a model.

IMHO, If there is some enhancement to do for the admin.. i think this 
should be it, along with more documentation/ how-to's & examples.


Thank you and kind regards

On Wednesday, February 10, 2016 at 1:25:20 AM UTC+2, Tim Graham wrote:
>
> The introduction to the admin in the docs [0] reads:
>
> "One of the most powerful parts of Django is the automatic admin 
>> interface. It reads metadata in your model to provide a powerful and 
>> production-ready interface that content producers can immediately use to 
>> start adding content to the site."
>>
>
> I've proposed [1] changing it to:
>
> "One of the most powerful parts of Django is the automatic admin 
>> interface. It reads metadata from your models to provide a quick and 
>> rudimentary interface where trusted users can manage content on your site. 
>>
>>
>> The admin has many hooks for customization but beware of trying to use 
>> those hooks exclusively. If your needs outgrow what the admin provides, it 
>> may be simpler to write your own views. The admin’s recommended use is as 
>> an organization’s internal management tool. It’s not intended for building 
>> your entire front end around."
>>
>
> However several reviewers have made comments like "I worry that the 
> description of the Admin sells it short. The Admin is actually brilliant 
> kit and works as advertised." and "Downgrading Django's admin from 
> "powerful and production ready" to "quick and dirty [old wording]" is very 
> harsh... And I fear this will not only lower user's expectations, but also 
> dev's carefulness!"
>
> I think part of the reason I raise this is that I'm getting weary of 
> adding hook after hook for customizing every little thing. I worry we'll 
> end up with an unmaintainable mess at some point. The latest proposal that 
> has me thinking about this adds ModelAdmin.orderable_by and 
> ModelAdmin.get_orderable_by() 
> for the use case of disabling sorting of a column in the change list [2]. 
> This topic also came up in the discussion of whether or not to add 
> ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done 
> yet). There's also an open question about whether or not to add a view 
> permission [4]. I don't want to discuss each of these decisions on this 
> thread but rather the broader question of whether putting a lot of effort 
> in this area is a direction we should pursue. I know there have been some 
> proposals of "admin2" but realistically I think the admin has too many 
> customizations points such that superseding it with something new and 
> innovative won't be feasible from a backwards compatibility standpoint.
>
> [0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
> [1] https://github.com/django/django/pull/6104
> [2] https://github.com/django/django/pull/6107
> [3] 
> https://groups.google.com/d/topic/django-developers/WrnhmTyLHuY/discussion
> [4] 
> https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/discussion
>

-- 
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/540baeb0-7f5a-4f45-b92c-ec4ce1979972%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[James Pic]

On Tue, Mar 15, 2016 at 1:59 AM, Ramez Ashraf  wrote:
>
> 1. Inlines  (FormView is like a teenager playing in the park next to Spartan
> Hero)

There are inlinemodelformsets you can use outside the admin.

> 2. Entry Log change message

django-activity-stream or even django-reversion

> 3. Various 3rd party support (ex: django-reversion)

It's not that the admin supports it, it's that django-reversion
provides templates which support the admin.

> 4. Changelist filters / search / table sort

django-filter, django-haystack, django-tables2

> 5. Change form (save,save and continue, save and add another)

You can make your form view mixin with this

> 6. Delete confirmation displaying related objects that will get deleted
> along (though sometimes big and heavy)

Delete view requires confirmation - it probably requires post at least.

Hope this helps

Best

James

-- 
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/CALC3KaeUJ62y5b%3DshH3jW2GkVe6fiXVxW-57aTqBE7ytWGenoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Markus Holtermann]

On Mon, Mar 14, 2016 at 12:34:40PM -0700, Florian Apolloner wrote:



On Monday, March 14, 2016 at 8:08:09 PM UTC+1, Michael Manfre wrote:


Simple is better. Anyone who needs/wants something more complex is not
prevented by Django from doing so.



+1 to that and what the rest said ;)


+1

As mentioned already on the PR, I'd go with the HTML5 validator. That
way we at least don't invent another standard.

WRT the backwards compatibility issues:

1) You might be able to submit an email address that passes the new
regex but not the old one. --> not an issue from my perspective

2) You're not able to submit an email address that does not pass the new
validator but the old one. --> Unlikely, but when the new field is of
type="email" your rather modern browser will tell you before Django
anyway

/Markus





Regards,
Michael Manfre

On Mon, Mar 14, 2016 at 2:31 PM, Aymeric Augustin <
aymeric@polytechnique.org > wrote:


Indeed, for some reason, the URL and email validators get anywhere from 2
to 8 changes in every Django version, and there’s no end in sight. (I
contributed to this. Sorry.)

Like James, I’m in favor of making the validation much more simple and
documenting it. This seems better than perpetually modifying it at the risk
of introducing regressions.

--
Aymeric.

On 14 Mar 2016, at 19:17, James Bennett 
wrote:

Personally I've long been in favor of drastically simplifying the email
regex and essentially telling people that if they want to support
triply-nested comments in a bang-path address they can write their own :)

Is there an actual compelling reason to not just pare it down to "word
characters and/or some punctuation, followed by an @, followed by some more
word characters and/or punctuation"?

On Mon, Mar 14, 2016 at 11:09 AM, Tim Graham  wrote:


On a pull request that proposes to tighten the validation of
EmailValidator [0], Ned Batchelder questioned the usefulness of this:

"Can I respectfully suggest that continuing to tweak this complex regex
to get asymptotically closer to perfection is not worth it? Especially to
fix false positives. What real-world problem is happening because
"gmail.-com" is accepted? "gmail.ccomm" is also accepted, but is just as
useless as an email address."

Collin Anderson proposed:

"I think we should try to just match the standard html  validation. I'd imagine that most uses cases would want to
match that. We might be able to use the regex verbatim from the standard
itself:

​
https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email
)
If people want to allow things outside of that they could use a custom
regex.
Though it gets more complicated when considering Unicode. Unicode needs
to get normalized to ascii before running through the official regex."

(Of course, this may be somewhat backwards-incompatible.)

What are your thoughts on this? I don't mind putting a halt to
enhancements to the validation as long as we can articulate a sensible
policy in the documentation.

[0] https://github.com/django/django/pull/5612

--
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/eb04034e-ea07-489f-aaf9-a08a5d241c4b%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-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/CAL13Cg8L6Gduwv4n%2BD68YqjEOmE1KWCKPPGnXjQr%2BR6a1HSSsA%40mail.gmail.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-develop...@googlegroups.com .
To post to this group, send email to django-d...@googlegroups.com
.
Visit this group at