Re: Composite fields

I think we can separate composite field implementation into two steps, first implement composite fields for user defined existing fields, then make it possible for fields to auto-create its subfields. I'm not sure of the meta issue. It seems in some cases you'll want access to the subfields, espec

Re: Composite fields

I'll reiterate that I mispoke when I said that "subfields wouldn't be added to model._meta". They would be, it's just that the contributor would be the CompositeField, not the model. Subfields are just wrappers for other field types and need a reference to the composite field. The difference that I

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

To respond to the other issues raised: On 2 March 2015 at 17:14, Tim Graham wrote: > I think it would be helpful to motivate this with some pseudocode of > specific use cases you are aiming to solve. Have you looked into whether > there are any related third-party projects related to your idea

Re: GSOC 2015 project ideas suggestion

I have seen that error on my own system Ubuntu 14.04 & Python 3.4.2 (installed from source), but didn't investigate the cause. I just installed Python 3.4.3, however, and don't have the problem there. Now I've reinstalled 3.4.2 and the error is resolved there as well. On Thursday, March 5, 2015

Re: GSOC 2015 project ideas suggestion

Hi, running django test suite under python 3.4.3 on my ubuntu 14.10 produce the below output ERROR: test_extract_function (utils_tests.test_archive.TestBzip2Tar) -- Traceback (most recent call last): File "/home/asif/foss/djan

Re: Composite fields

While I like your approach, Thomas, I should also note that I'm not an expert on those parts of Django and haven't kept up with the Michal's proposal. With respect to migrations I like Anssi's approach to have both `author` and `author_id` in _meta.fields. It will probably simplify a couple of

Re: Composite fields

Well, I was thinking that although the subfields would still be added to Model._meta.fields, you could - add an 'include_subfields=False' default argument to get_fields() - only allow direct lookups of subfields via Model._meta.get_field(composite).get_subfield(subfield) or (alternately, depend

Re: Composite fields

I think `Model._meta` may well always want all the concrete underlying fields included somehow, especially for migrations work. A possibility for your external `MoneyField` could be to add other fields using `contribute_to_class`, though this may be a bad idea... On 5 March 2015 at 14:47, Thomas S

Re: Composite fields

> Turns out this was a bad idea, after around 1700 lines changed everything was broken and there were multiple hard to debug failures. Yeah, been in this situation too many times to count. > Split ForeignKey to a concrete field instance, and a related field instance. After this all related field

Re: RE Composite fields-/ Multi Primary / Foreign keys

Hi Aron, this discussion thread might interest you to collaborate https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!topic/django-developers/MZUcOE6-7GY On Tuesday, February 24, 2015 at 12:14:19 PM UTC+6, Aron Podrigal wrote: > > Hi, I just came across a project that requires

Re: Place on a server

On 03/05/2015 11:47 AM, Erik Romijn wrote: Hello, The best place to get answers to your questions is the django-users email list, > - the web interface is

Re: Composite fields

I've started doing some refactorings to the fields/related.py. The ultimate goal is to have field.rel (ForeignObjectRel) instances to be Field subclasses. I first went ahead and did exactly this with the idea of changing everything in one go. Turns out this was a bad idea, after around 1700 li

Re: Place on a server

Hello, The best place to get answers to your questions is the django-users email list, mailto:django-developers@googlegroups.com>> - the web interface is >. If you decide to ask on that