About one year ago I wrote a CompositeField implementation, which I
proposed as a clean way of grouping fields together, while making it
easy to reuse that composition of field:
https://bitbucket.org/mp/django-composite-field
It's a slightly different approach and is centered around defining a
fi
On May 17, 5:32 pm, Michal Petrucha wrote:
> Proper subquery support is something that can be addressed once the
> rest of the implementation is stable.
To me the plan looks very reasonable (both disallowing subqueries and
converting to disjunction form), unless there is some part in the
internal
On Tue, May 17, 2011 at 02:05:10AM -0700, akaariai wrote:
> On May 12, 2:41 pm, Michal Petrucha wrote:
> > Due to the nature of this field type, other lookup filters than
> > ``exact`` and ``in`` would have unclear semantics and won't be
> > supported. The original plan was to also exclude support
On May 12, 2:41 pm, Michal Petrucha wrote:
> Due to the nature of this field type, other lookup filters than
> ``exact`` and ``in`` would have unclear semantics and won't be
> supported. The original plan was to also exclude support for ``in``
> but as it turns out, ``in`` is used in several place
On Thu, May 12, 2011 at 5:16 PM, Carl Meyer wrote:
>
> On 05/12/2011 06:41 AM, Michal Petrucha wrote:
>
> On Thu, May 12, 2011 at 02:49:03PM +0100, Tom Evans wrote:
> The value of a CompositeField will be represented by an instance of a
> > CompositeValue class. This will be a descendant of tupl
On 12/05/11 12:41, Michal Petrucha wrote:
> 1) Leave out the ``unique`` option and live with ``unique_together``.
>This would pribably imply also leaving out ``db_index``, otherwise
>the API would be a complete mess.
>
> 2) Allow ``CompositeField.unique`` but also keep ``unique_together``
> > 2) Allow ``CompositeField.unique`` but also keep ``unique_together``.
> >The problem I see with this approach is that there would be two
> >quite different ways to achieve the same effect.
>
> I agree with Javier - I favor option 2. In my mind, although the final
> result at the databa
On Fri, May 13, 2011 at 09:01:19AM -0700, onelson wrote:
> I'm not that familiar with GFK's and how they work in django, but I just
> wanted to check...
> Will we have (non-generic) FK support for this, or is that another
> can-o-worms that won't get touched for some time?
Adding support for co
I'm not that familiar with GFK's and how they work in django, but I just
wanted to check...
Will we have (non-generic) FK support for this, or is that another
can-o-worms that won't get touched for some time?
Regards,
Owen
--
You received this message because you are subscribed to the Google
Hi Michal,
I'm looking forward to seeing this project take shape! Comments below:
On 05/12/2011 06:41 AM, Michal Petrucha wrote:
[..]
> The constructor of a CompositeField will require at least two
> positional parameters, each positional parameter will be a single
> atomic field. The order of th
On Thu, May 12, 2011 at 8:49 AM, Tom Evans wrote:
> unique/unique_together: They should both be supported. unique_together
> should raise a PendingDeprecationWarning, and it should disappear
> according to the deprecation timeline. unique_together only exists as
> a Meta option as there is no fiel
On Thu, May 12, 2011 at 02:49:03PM +0100, Tom Evans wrote:
> Hi Michal
>
> This looks really, really good. A few comments:
Thanks for the response.
> Value of a composite field: It should descend from namedtuple. From
> 1.4 onwards, Django only supports 2.5+, so it's not necessary to fudge
> thi
On Thu, May 12, 2011 at 12:41 PM, Michal Petrucha
wrote:
> As most of you have probably noticed by now, in a week and a half I'll
> start working on the implementation of composite fields. Before that
> we should probably agree on the final form of the API.
>
>
Hi Michal
This looks really, real
13 matches
Mail list logo
