Re: Can we move the activity on this list to the Forum now?
Hi I can't speak for others, but I personally STRONGLY value the fact that this discussion happens in my inbox, not on yet another website. But perhaps the forum still supports this reading mode? On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote: > Hi all. > Given the issues with Tom's access to the mailing list here, and the > fact that the Forum has been active for a few years now, and is a > great success, I'd like to revisit whether we can move on-mass (all > few of us :) over there? > We'd enjoy the benefits of a much nicer system. We'd not have issues > such as the current, and we'd be one less item in the pocket of a > mega-corp. (You can rank those as you will :) > Initially when this can up (a long time ago) Andrew and Tom discussed > whether we could import the history here into the forum. I think > that's unnecessary. We can still access the history here (until such > a day as Google takes it away) at worst -- but, rather, if we can get > an archive we could import it into read-only Datasette instance[0] — > and that would likely be good enough. > Can we move now? > Thanks. > Kind Regards, > > Carlton > > > [0]: I'd happily do this. > > > > -- > > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/101f4e6d-9b83-47ab-bb1b-b571402e037dn%40googlegroups.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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4a329eadd5606c2f94aa5638e079800f1914d0d7.camel%40gammascience.co.uk.
Re: Make timeout property for PasswordResetTokenGenerator
Hi If it's intended as a reference implementation, then I would expect PasswordResetTokenGenerator to use Signer or TimestampSigner internally , but I was surprised to discover that it didn't use either. Isn't those entry points the better API to advise for use rather than the direct use of hmac based algorithms? On Tue, 2022-08-23 at 12:45 +0200, Carlton Gibson wrote: > Hi Alexander. > I think the point from ticket #30423 is that we don't want to > complicate PasswordResetTokenGenerator in order to make it into a > more general purpose token generator. > Much better is for you to take inspiration from it to implement what > you need in your project. (It's the underlying signing code that you > really want to lean on Django for.) > > Kind Regards, > > Carlton > > > On Mon, 22 Aug 2022 at 17:26, Alexander Voloshchenko < > voloshchenkoalexan...@gmail.com> wrote: > > During project development our team needs to create several types > > of tokens. One of them will be used in case of account reset > > password. The second one is for account activation. Django itself > > has a good class for token generation called > > PasswordResetTokenGenerator. And now for account activation, we are > > using our own class called ActivationTokenGenerator, a subclass > > of PasswordResetTokenGenerator with > > overridden _make_hash_value method. And it works, but there is one > > problem. And this problem is called "timeout". For now, every token > > created with PasswordResetTokenGenerator will have timeout > > from settings.PASSWORD_RESET_TIMEOUT variable and can be changed > > only by changing this variable value. But what if we need different > > timeouts for different tokens? And I don't think we want changing > > timeout for activation token using a variable which is screaming > > about password reset (PASSWORD_RESET_TIMEOUT), we would like to use > > smth called ACTIVATION_TOKEN_TIMEOUT > > So there is a solution: why not create a timeout property > > for PasswordResetTokenGenerator class? Almost in the same way as it > > was done with _secret and algorithm fields.So our development team > > come up with an idea to create a PR which will add this > > functionality to the Django project. But before this we decided to > > search similar solutions in django PRs. And we found them! Ticket > > 30423 https://code.djangoproject.com/ticket/30423 sounds good > > enough, but it was closed with wontfix label.So the question is: > > why not to add this fine feature to > > the PasswordResetTokenGenerator ? And if people find this useful - > > why not to merge one o the existing PRs? > > > > > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6458aad7056857164d976b1c7ce46bcd0249d292.camel%40gammascience.co.uk.
Re: Django website Down
It may have had something to do with this? I seem to remember fastly did offer some OSS projects some CDN services. https://www.bbc.co.uk/news/technology-57399628 On Tue, 2021-06-08 at 14:17 +0100, Wadinga Leonard Ngonga wrote: > It’s up, I can access it from my location(Buea, Cameroon). Try with a > VPN it could be your ISP. > > > > Sincerely, > Wadinga Leonard. > > > On 8 Jun 2021, at 14:13, danushka padrushka < > > danupadrus...@gmail.com> wrote: > > > > Hi, > > > > Not sure if this is the right email to report it but Django website > > is down, > > > > -- > > 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 view this discussion on the web visit > > https://groups.google.com/d/msgid/django-developers/6EAF8BA5-DD5A-4CF6-85D6-B4216EA5A07E%40gmail.com > > . > > > > > > > > > > Dan > > > > Sent from my iPhone > > > > -- > > 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 view this discussion on the web visit > > https://groups.google.com/d/msgid/django-developers/6EAF8BA5-DD5A-4CF6-85D6-B4216EA5A07E%40gmail.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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/71749f2f705b9c72827117d3defab2a7f1b35074.camel%40gammascience.co.uk.
Re: `select_related` relation control
On Thu, 2020-12-03 at 11:58 +, Adam Johnson wrote: > What prevents you from using select_related with an explicit list of > relations that you *do* want? well the fact the select_related() call is in third party code. In the most common case for us this is contrib.admin. So we are forced to be a bit more explicit in the ModelAdmin Meta definition than we would normally be. It no bad thing., but it occasionally catches team members out. It fails fast here, so it's not going to go unnoticed like a performance problem can. Thanks for the blog link and the reference to django-auto-prefetch, there is some good stuff in there to think about. -- Roger Gammans Gamma Science Ltd. (GB Nr. 07356014 ) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7913088a6a1f28e325c57c0ab2892a3b6cbb2576.camel%40gammascience.co.uk.
`select_related` relation control
Hi A recent question on one of the other django mailing lists reminded me of this: I have a very edge (and almost certainly off the end of 'supported') use case, where I would like to mark some relations on a model, as having select_related() disabled. More specifically the requirement is that qs.select_related() (with no args) doesn't include the marked relations. It doesn't look like there is a way of doing this in the ORM as it stands - is this correct? I could probably work up this feature as a field flag, but given that it's completely niche, I wondered what the chance of the core team accepting it was. (with unittests)? -- Roger Gammans Gamma Science Ltd. (GB Nr. 07356014 ) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0d9b15f264065bf090e7413e80f27d022d21a227.camel%40gammascience.co.uk.
Re: Oddity found in password creation
On Tue, 2020-10-06 at 23:26 -0700, James Bennett wrote: > > Passwords obtained from previous breach corpuses. There even appears to be a 3rd party validator for this. Although it only checks for inclusion, not total number breaches that password was included in, which might be a useful indicator you find it feel too strict. https://github.com/koslibpro/django-pwned-password/ -- Roger Gammans Gamma Science Ltd. (GB Nr. 07356014 ) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/70b031952479d4f9d58767c5abcf5248d17be4a4.camel%40gammascience.co.uk.
Re: Pendolumn
On Tue, 2020-09-08 at 18:01 -0700, Damiano Porta wrote: > Hello everybody!Can I use Pendolumn (https://pendulum.eustace.io/) as > default datetime library for my models? You probably want to write a custom DateTimeField subclass and override to_python(). Pendolumn date times claim to be stdlib datetimes (eg the doc says instance(pendulom_datetime-obj, datetime.datetime) is True ) so conversion the other way may work fine with the existing DateTimeField code. See here: https://docs.djangoproject.com/en/3.1/howto/custom-model-fields/#converting-values-to-python-objects Nb: This is probably a question for the django-users list not the django-developers list. -- Roger Gammans Gamma Science Ltd. (GB Nr. 07356014 ) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0874de593ac3d4cdd79a8314dd2af302db31532d.camel%40gammascience.co.uk.
Pickling - Re: Cache framework
On Mon, 2020-08-17 at 10:30 +0200, Jure Erznožnik wrote: > While at it, I have seen that various backends now implement > their own pickling. With the exception of memcached, they > all > implement the same thing. Perhaps it would be beneficial to > move pickling functionality to BaseCache? > > > > I've noticed in my applications when I've used django cache in performance sensitive hot paths, often it shifts he slowest portion from the databases (or whatever I'm caching) to the unpickler. This makes me wonder if there is a argument to abstract the pickling, so that application can do something special in their uses case. -- Roger Gammans Gamma Science Ltd. (GB Nr. 07356014 ) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e619056268f40c4d909daf5cddf47885a8cc6cdf.camel%40gammascience.co.uk.
Re: The blacklist / master issue
Funny you should say that but the git developers mailing list in is awash with patches and shouting about just this at the moment. It looks likely the patches will go in too - so that's not much of an arguement against. On Tue, 2020-06-16 at 16:35 +0300, אורי wrote: > I think master is the default branch name in any Git repository. It's > not about Django and even not GitHub. Do you want to change the > default branch name in Git? > אורי > u...@speedy.net > > On Mon, Jun 15, 2020 at 7:28 PM Tom Carrick wrote: > > This ticket was closed wontfix as requiring a discussion here. > > > > David Smith mentioned this Tox issue stating it had been closed, > > but to me it seems like it hasn't been closed (maybe there's > > something I can't see) and apparently a PR would be accepted to add > > aliases at the least (this is more recent than the comment on the > > Django ticket). > > > > My impetus to bring this up mostly comes from reading this ZDNet > > article - it seems like Google have already made moves in this > > direction and GitHub is also planning to. Usually Django is > > somewhere near the front for these types of changes. > > > > I'm leaning towards renaming the master branch and wherever else we > > use that terminology, but I'm less sure about black/whitelist, > > though right now it seems more positive than negative. Most > > arguments against use some kind of etymological argument, but I > > don't think debates about historical terms are as interesting as > > how they affect people in the here and now. > > > > I don't think there is an easy answer here, and I open this can of > > worms somewhat reluctantly. I do think Luke is correct that we > > should be concerned with our credibility if we wrongly change this, > > but I'm also worried about our credibility if we don't. > > > > > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1b47e74f1811390add42c91dab4ccea104b89fcf.camel%40gammascience.co.uk.
Re: Implement QuerySet.__contains__?
On Tue, 2020-06-02 at 11:31 -0700, Javier Buzzi wrote:
> ps @roger
>
> >>> timeit.timeit('m.GL.objects.filter(pk=x.pk)', setup='import
> myapp.models as m;x = m.GL.objects.all()[324]', number=100)
> 0.05818330496549606
>
> is not doing anything, add a `.exists()` or `len(..)` or something to
> evaluate the queryset. That number is WAY too low.
Yes, of course. That makes me feel silly, on both counts - the
evaluations and the number of iterations. I made number of iterations
low;because I started with a test which a single iteration was taking
multiple seconds and it that case the default number was way to high
for the quick test I was offering. More critically the x in qs; depends
on where in the qs the object is and it doesn't matter how big if you
only look at the beginning.
I reran it; but which shows different results.. See the following re
run. Construction here is more complicated to show avg microsecs; per
iteration, note the vary iteration lengths, actual runtime was aimed to
be between 20secs and a minute or so.
>>> # Searching for first in queryset>>> n=10_000_000 ;timeit.timeit('x
in qs', setup='import myapp.models as m;qs = m.GL.objects.all();
qs2=qs;i=len(qs2);x=qs[0]',
number=n)/(n/1_000_000)0.4136358265765011>>> n = 100_000 ;
timeit.timeit('m.GL.objects.filter(pk=x.pk)', setup='import
myapp.models as m;x =
list(m.GL.objects.all())[0]', number=n)/(n/1_000_000)124.9944525491446
3>>> # Searching for last in queryset.>>> n=1000; timeit.timeit('x in
qs', setup='import myapp.models as m;qs = m.GL.objects.all();
qs2=qs;i=len(qs2);x=qs[i-1]',
number=n)/(n/1_000_000)50741.098549216986>>> n = 100_000 ;
timeit.timeit('m.GL.objects.filter(pk=x.pk)', setup='import
myapp.models as m;x = list(m.GL.objects.all())[-
1]', number=n)/(n/1_000_000)118.99649207945913
--
Roger Gammans
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/3928039038bac9b52279294f7efcac318dc80388.camel%40gammascience.co.uk.
Re: Implement QuerySet.__contains__?
Hi,
Here are some performance numbers against a local SQLite in case any
one is interested. GL has about 40,000 records for reference.324 was
just a random number chosen, of different 'in's
>>> sys.version'3.7.2rc1 (default, Dec 12 2018, 06:25:49) \n[GCC
8.2.0]'>>> django.__version__'3.0.6'>>> import myapp.models as m>>> x =
m.GL.objects.all()[324]>>> x in m.GL.objects.all()True
>>> import timeit>>> timeit.timeit('m.GL.objects.filter(pk=x.pk)',
setup='import myapp.models as m;x = m.GL.objects.all()[324]',
number=100)0.05818330496549606>>> timeit.timeit('x in qs',
setup='import myapp.models as m;qs = m.GL.objects.all(); x=qs[324]',
number=100)1.5688817161135375
On Tue, 2020-06-02 at 05:53 -0700, Tim Graham wrote:
> It may help to know that QuerySet.__contains__() was implemented
> until Django 1.6 when chunked reads were removed from QuerySet
> iteration:
>
> https://github.com/django/django/commit/70679243d1786e03557c28929f9762a119e3ac14
> On Tuesday, June 2, 2020 at 7:43:25 AM UTC-4, Aymeric Augustin wrote:
> > > On 2 Jun 2020, at 13:30, Florian Apolloner
> > > wrote:
> > >
> > > On Tuesday, June 2, 2020 at 11:28:34 AM UTC+2, Adam Johnson
> > > wrote:
> > > > > If you already fetched the queryset, `if obj in queryset`
> > > > > will make a new database query
> > > >
> > > > I don't see why we couldn't implement __contains__ to do a walk
> > > > through _result_cache if it has been fetched?
> > > >
> > >
> > > we are doing the same for len() IIRC. I have to say it sometimes
> > > makes it a little bit hard to debug, but if it is documented as
> > > such it should be okay.
> >
> > These are good points.
> >
> > As far as I can tell, the current implementation of __len__ is to
> > fetch the whole queryset:
> >
> > def __len__(self):
> > self._fetch_all()
> > return len(self._result_cache)
> >
> > I'm almost sure doing an automatic .count() was discussed in the
> > past. I don't remember why we rejected it — perhaps because in most
> > cases, when you need the length of a queryset, you will also
> > iterate it?
> >
> > The suggestion for __contains__ is similar: doing an automatic
> > .filter(pk=obj.pk).exists(). We could do it only if the queryset
> > isn't fetched yet, but I'm afraid this may be too magical. Is it
> > reasonable to have `total = len(queryset); found = obj in queryset`
> > make one SQL query while `found = obj in queryset; total =
> > len(queryset)` makes two queries?
> >
> > Now I'm worried that we may be making inconsistent decisions
> > between __len__ and __contains__... Let's make sure we're
> > consistent across dunder methods.
> >
> > --
> > Aymeric
> >
> >
>
>
>
> --
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/55b4d7e0-ba30-48b2-8005-d27adacc7fd0%40googlegroups.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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/69fdfe26be34d37a09cfe9dc7f5cc9a4c580d1d9.camel%40gammascience.co.uk.
Re: Pre-DEP: Meta.without_primary_key (related to CompositeFields)
Hi, This would be useful for us too ; this is our use-case, again this is a legacy schema which are rebuilding the system to use django, but there are some models which we are using composite-pk support for due to the following. Having these feature many we could use a vanilla django.(eg one without local patches) Many of the table in our system are effectively, what django refers to a through table. Eg, the join table in a many-2-many relationship , or more often then not multi-join. We almost always fetch by a a the set of joined PKs and those have been used a composite primary key on the table. In this use case we are accepting not having admin tables as in many of them are computed detail tables, but we still have uniqueness guarantees at the SQL level since the Db still has the tables defined with a PK. Django's query builder as standard cannot interact with these tables, adding this option will allow us to code model which partially capture the semantics and build queries against them. I don't think we lose the ability to use get() as there is still a uniqueness guarantee on the table; it just it is partially hidden from the orm . In some cases these are our largest tables with 10^7 or even 10^8 rows, so adding an additional field is not undertaken lightly. We also have an additional restriction in that the legacy code is still active is some part of our system and still need to interact with these tables as well. I hope that might explain one way this option could be helpful. On Tue, 2017-05-23 at 11:31 +0300, Shai Berger wrote: > Hi, > > Thank you for making this suggestion. > > It is my guess that allowing pk-less models will place quite a burden > on many > parts of Django, which assume a PK exists. There may also be other > solutions > to the problem you raise -- e.g. changing the legacy table to add a > PK, > perhaps while providing a pk-less view to any legacy systems which > need to > access it. > > In general, SQL database tables without any uniqueness guarantee are > an > antipattern, which I don't believe Django should support. The > question remains > how much such a feature can be made to contribute towards composite > keys. > > All in all, I would like to know more about your use case -- if you > are going > to have no get/delete, no Admin, no updating save, how exactly are > you going > to use these models? As you may be aware, since the Meta API > formalization, it > is possible to create pseudo-models which are good enough for many > purposes, > without changing Django and with much less strict adherence to "real" > models' > behavior. Perhaps that is the way to go? > > HTH, > Shai. > > On Monday 22 May 2017 21:50:07 sky.duv...@moveon.org wrote: > > Hi, > > > > We have several legacy database tables that don't have primary > keys. With > > older versions of Django, we've hacked it by lying about a field > that was > > not a primary key but recent Django versions validate pks more > strictly. > > > > Some (but not all) of our legacy tables have multiple primary keys > -- i.e. > > are unique only across a few fields. This harks to the > CompositeField work > > and discussion [0]. > > > > But CompositeFields are not enough for us, some of our tables are > > essentially append-only, and have no uniqueness constraints across > any/all > > fields. It also seems like CompositeField has stalled several > times > > precisely because we are spiking to a very complex end goal. > > > > I'd like to propose, both as an incremental step to CompositeFields > and > > something useful in itself, a model Meta option for > `without_primary_key` > > -- if Meta.without_primary_key=True then it would turn off the > complaints > > during model validation, etc. One might object that things like > > get/delete/caching can't work with that model. However those > features > > can't be supported in tables without a primary key anyway. > > > > Incrementally, after without_primary_key is implemented/supported, > we could > > then add features for models without_primary_key but also has a > > Meta.unique_together value across some fields -- i.e. start trying > to > > support inheritance and/or ForeignKey references to those tables, > building > > up support. > > > > I've started looking at how deep a change this would be, and > believe it's > > pretty tractable. > > Before I get too involved with a DEP and PR, what do people think? > > > > /sky > > > > [0] Most recent thread: > > https://groups.google.com/forum/#!searchin/django-developers/primar > y$20keys > > |sort:date/django-developers/wakEPFMPiyQ/ke5OwgOPAQAJ > -- 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
Re: Composite key development
On Mon, 2017-02-27 at 21:03 -0800, Asif Saifuddin wrote: > Hi Julian, > > > I have been also reviewing and studying the previous works, deps, discussions, codes and tickets. I have also been working to prepare a new dep based on the previous works. > I haven't had a chance to review Michael's code (is there a github link?) but I think the composite field approach is almost certainly a sensible route. Which is a shame because it adds quite a bit of extrope tha refactor work for me. ;-). The code I have got[2], does not take that route[1], shows the switch between single field and composite primary adds a lot of complexity to far too many (IMHO) code routes. If it was a handful I wouldn't worry a great deal, but there is a lot of complexities which fall on the admin code which don't quite fall out as neatly as I would like. Hence I hope that by providing a named composite field, then we mitigate the issues above as arguable we still only have single field PK, but that that field is itself composite which may well mitigate the issues I have been seeing. [1] We took a patch from somewhere which allowed multiple primary_key=True specifications in the model. [2] Initially developed by by one of by colleagues based on some other patches he found - We may unfortunately have lost the attribution. -- Roger Gammans <rgamm...@gammascience.co.uk> -- 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/1488267322.2524.18.camel%40gammascience.co.uk. For more options, visit https://groups.google.com/d/optout.
Re: Composite Primary Keys
Hi, We've got some patches that we are using in production, against 1.8 . Out long term aim would be to get them ready for a PR , but I they are missing all sorts of things, such unit tests and migrations (we don't use migrations at the moment - long story, so these haven't been tested). The other thing which I think is maybe is some of the prefetch_related API, I've had difficulties with it and just worked around it in my app. And it really needs another user at least to kick the tires which we aren't exercising - we mainly use because we have a lot of intersection tables of natural / 'foreign' keys and a legacy model which didn't add a serialized Pk for these. I'd also like to know how interested the core developers would be in merging some support for this. On Tue, 2016-02-16 at 17:38 -0800, Cristiano Coelho wrote: > Hello there, > > What's the status for this? This > (https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys) is 3 > years old (last edit) and the links on it are even older. Googling > around only gave me some very old projects so it wasn't good neither. > > -- > 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/b2873ece-39bb-4536-b23d-d988c7122204%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/1455702835.27233.10.camel%40gammascience.co.uk. For more options, visit https://groups.google.com/d/optout.
