Re: Composite fields

I have implemented something like this: https://bitbucket.org/portonv/composite-fields (I did my implementation before reading my thread.) Please feel free to use and modify my code. Well, now I should read this thread and https://github.com/django/deps/blob/master/draft/0191-composite

Re: Composite fields

Thomas, Please be patient. As for me, I'm focused on finishing up the 1.8 release. I've added composite fields and a link to your DEP to the 1.9 roadmap to help ensure it gets attention for that release cycle: https://code.djangoproject.com/wiki/Version1.9Roadmap On Wednesday, March 18, 2015

Re: Composite fields

Dev discussions typically happen on #django-dev on the Freenode IRC network. -- C On 18 March 2015 at 19:54, Thomas Stephenson wrote: > IRC discussion sounds fine with me, but I'd like to be involved. What's > the channel? > > Thomas > > On 18 March 2015 at 15:47, Asif

Re: Composite fields

IRC discussion sounds fine with me, but I'd like to be involved. What's the channel? Thomas On 18 March 2015 at 15:47, Asif Saifuddin wrote: > but? IRC discussion? > > On Tuesday, March 17, 2015 at 9:09:49 PM UTC+6, Thomas Stephenson wrote: >> >> Not impatient or anything,

Re: Composite fields

but? IRC discussion? On Tuesday, March 17, 2015 at 9:09:49 PM UTC+6, Thomas Stephenson wrote: > > Not impatient or anything, but... > > Bump. > > On 13 March 2015 at 14:07, Thomas Stephenson > wrote: > >> All the null handling stuff has been removed from the specification and

Re: Composite fields

Not impatient or anything, but... Bump. On 13 March 2015 at 14:07, Thomas Stephenson wrote: > All the null handling stuff has been removed from the specification and > replaced with slightly more stringent restrictions on `value_to_dict`. > There is an updated version which

Re: Composite fields

All the null handling stuff has been removed from the specification and replaced with slightly more stringent restrictions on `value_to_dict`. There is an updated version which includes that change, plus a couple more alterations that were discussed here and on the PR available here.

Re: Composite fields

On Mon, Mar 9, 2015 at 8:06 AM, Thomas Stephenson wrote: >> It doesn't result in good table design and adds restrictions/complication >> to the ORM/migrations. > > Well, honestly, making all subfields always nullable (whether it is or not) > in order to support the composite

Re: Composite fields

mas Stephenson >>>> wrote: >>>>> >>>>> Aymeric, >>>>> >>>>> Thanks for your input. I feel some of your concerns have been >>>>> addressed in the DEPs I made, which have included quite a bit of input >>>>

Re: Composite fields

int() > > because of the inheritance limitations (which I might have to lift in the > medium-long term anyway, but which I'd like to preserve for as long as > possible to keep the initial implementation and API simple). > > The point is (no pun intended) that I can't really think of

Re: Composite fields

mplementation was done without too much >>> consideration of prior attempts, because I was more interested in getting >>> something working than I was in learning from the past. >>> >>> 2) I agree. The new syntax I've proposed is to add one or more >>> class-leve

Re: Composite fields

ods to the django.db.models API. The new syntax for >> "inline" fields is: >> >> class MyModel(models.Model): >> x = models.IntegerField() >> y = models.IntegerField() >> point = models.constrain(x, y, unique=True) >> > good > >> &

Re: Composite fields

ructors (and all the > other field classes) make absolutely no sense when you're mainly leveraging > composite fields to provide a table level constraint to two existing > fields. Also there are some things that are commonly done in practice (like > providing `verbose_name` as a positio

Re: Composite fields

spend too much time > on > code; it my experience it’s harder to reuse and code matters much less > than > design. > > 2) The syntax for inline composite fields doesn't look very nice. Could > you > simplify it somehow? Anssi’s proposal is good. I assume tha

Re: Composite fields

tegerField() point = models.constrain(x, y, unique=True) The reason for not using the CompositeField constructor is that a lot of the options which make sense for standalone field constructors (and all the other field classes) make absolutely no sense when you're mainly leveraging compos

Re: Composite fields

. The main goal of this exercise is to guarantee that you don’t overlook a use case or an argument that made consensus in the past. (Don’t spend too much time on code; it my experience it’s harder to reuse and code matters much less than design. 2) The syntax for inline composite fields doesn't look very

Re: Composite fields

: >> >> Y'OK. I'll create DEP 191 for the composite fields which point to model >> fields defined on the model (using the syntax you provided above) and DEP >> 192 for composite fields which define their own subfields (using the model >> syntax). >> >&g

Re: Composite fields

. Thomas On Friday, March 6, 2015 at 9:52:56 PM UTC+11, Thomas Stephenson wrote: > > Y'OK. I'll create DEP 191 for the composite fields which point to model > fields defined on the model (using the syntax you provided above) and DEP > 192 for composite fields which define their o

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

yeah, turns out I got busy with some other work and did not have time to work on this. Fortunately, Thomas has done a lot of great work yet. I'll just follow up on that thread. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to

Re: Composite fields

Y'OK. I'll create DEP 191 for the composite fields which point to model fields defined on the model (using the syntax you provided above) and DEP 192 for composite fields which define their own subfields (using the model syntax). I was getting confused trying to create a specification which

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

Re: Composite fields

d be a subfield of foreign key (then >>>> model._meta would not contain two entries for the foreign key). >>>> Unfortunately that would open the door to composite field inheritance, but >>>> it could be handled like enum inheritance is handled in python -- you can >>

Re: Composite fields

uld not contain two entries for the foreign key). >>> Unfortunately that would open the door to composite field inheritance, but >>> it could be handled like enum inheritance is handled in python -- you can >>> subclass as much as you want, but you can't declare additional

Re: Composite fields

handled like enum inheritance is handled in python -- you can >> subclass as much as you want, but you can't declare additional fields on >> subclasses. >> >> If that happened, then composite foreign keys would be a lot easier (but >> still work that can be def

Re: Composite fields

eritance, but > it could be handled like enum inheritance is handled in python -- you can > subclass as much as you want, but you can't declare additional fields on > subclasses. > > If that happened, then composite foreign keys would be a lot easier (but > still work that can be deferred)

Re: Composite fields

ut you can't declare additional fields on subclasses. If that happened, then composite foreign keys would be a lot easier (but still work that can be deferred). > Michal Petrucha did a lot of work to add composite fields to Django. The syntax he had was: I'm not exactly a fan of that syntax.

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_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: Composite fields

ForeignObjectRel Field subclass. This will likely rename the classes to something like ReverseForeignKey, ReverseManyToMany and so on. - Finally, add the new reverse field instances directly to the remote model's _meta This is just clean-up in the fields/related.py. The composite fields work doesn't need

Re: Composite fields

. Thomas On Thursday, March 5, 2015 at 2:47:51 PM UTC+11, Loïc Bistuer wrote: > > Hi Thomas, > > fields/related.py is begging for a refactor of the existing relational > fields, and ideally we'd build composite fields on top of this refactor. > > The ORM

Re: Composite fields

Hi Thomas, fields/related.py is begging for a refactor of the existing relational fields, and ideally we'd build composite fields on top of this refactor. The ORM has seen huge changes in the recent past: migrations, expressions, lookups, and last but not least a *public* footprint in Model

Re: Composite fields

gt; 2 cents > > On Thursday, 5 March 2015 13:59:44 UTC+11, Thomas Stephenson wrote: >> >> Hey there, >> >> Yeah, I've looked through some (probably not all) of the previous >> proposals to support composite fields. I was going to wait until some more >> wo

Re: Composite fields

nsidering the past two proposals I've made here, I doubt I'll get more > than an echo chamber effect on this one. > > For the past week or so I've spent a bit of time on a feature I've always > wanted to see land in django -- composite fields. The tickets have been > open in the bug tra

Re: Composite fields

Hey there, Yeah, I've looked through some (probably not all) of the previous proposals to support composite fields. I was going to wait until some more work had been done to split concrete fields from virtual fields (ticket 16508 <https://code.djangoproject.com/ticket/16508>), because I t

Re: Composite fields

able to intelligently comment on your proposal is very small. I can think of a few people that would have some interest, including Ansii, Loic, and probably Marc. I'm interested in the ORM in general, but I really have no opinion on Composite Fields at the moment, so I have nothing to really

Re: Composite fields

Have you reviewed all the existing works on trying to add composite fields? I know several managed to reach a level of maturity that was almost merge quality, and am sure I heard some of the recent ORM changes would ease support. On 5 March 2015 at 11:42, Thomas Stephenson <ovan...@gmail.

Re: Composite fields

amber effect on this one. > > For the past week or so I've spent a bit of time on a feature I've always > wanted to see land in django -- composite fields. The tickets have been open > in the bug tracker for quite some time (and there's a few related ones, such > as multi-column primary

Composite fields

Considering the past two proposals I've made here, I doubt I'll get more than an echo chamber effect on this one. For the past week or so I've spent a bit of time on a feature I've always wanted to see land in django -- composite fields. The tickets have been open in the bug tracker for quite

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

Hi Aron, Short version - if you're eager to look into this, we're eager to have composite keys in Django - it's probably one of the last features I can think of that was discussed for the 1.0 release but we bumped so that "we can add it for 1.1". (ahem. :-) Yes, there have been a lot of changes

RE Composite fields-/ Multi Primary / Foreign keys

Hi, I just came across a project that requires this functionality of multi primary/foreign keys. So I'm bumping up this thread again. There

Re: [GSoC] Composite fields once again

This sounds exciting. I can't wait for this to land in master. Thanks, Michal! On Sunday, June 2, 2013 10:22:36 AM UTC-4, Michal Petrucha wrote: > > Hello everyone, > > I'm happy to announce that throughout the summer I'll be officially > working on composite fields under

Re: [GSoC] Composite fields -- another status report

Hello everyone, a lot of time has passed since I last posted a status report here and I apologize for that. Composite ForeignKeys were a fairly simple thing to implement with all the required parts already in place. There is one edge case that I'd like to handle, where Django would detect

[GSoC] Composite fields -- irregular status report #4

Hello, Last week I finished an implementation of CompositeField with support for backend-dependent IN lookups. During the past few days I also added support for composite primary keys to the admin. The latest work is available in the soc2013/composite-fields branch [1]. As a reminder

Re: Composite fields -- (ir)regular status report #3

On Monday, July 22, 2013 2:48:00 AM UTC+3, Michal Petrucha wrote: > > Hello, > > I have some awesome news today. At long last I managed to finally get > the refactor of ForeignKey to pass the entire test suite. It's only > one configuration (CPython 2.7 + SQLite), but it's a start. Due to the

Re: Composite fields -- (ir)regular status report #3

On Mon, 22 Jul 2013, Michal Petrucha wrote: I have some awesome news today. At long last I managed to finally get the refactor of ForeignKey to pass the entire test suite. That is awesome news! Well done Michal! I am really looking forward to having this feature available in Django.

Composite fields -- (ir)regular status report #3

Hello, I have some awesome news today. At long last I managed to finally get the refactor of ForeignKey to pass the entire test suite. It's only one configuration (CPython 2.7 + SQLite), but it's a start. Due to the nature of my changes, I expect that only database creation should be prone to

Re: [GSoC] Composite fields once again -- irregular status report #2

right now, unfortunately, it seems that this lag will increase further. Well, I was too optimistic in my proposal... The good news is that the changes I'm required to make at this stage will make support for composite fields even easier to implement than I anticipated. Feel free to check out the code

[GSoC] Composite fields -- weekly status report no. 1

Hello, The official coding period has started a week ago, therefore I guess a progress report is in order. As far as changes to the proposal are concerned, it seems there aren't any. There haven't been any objections or other suggestions to improve the proposal, other than the updatable primary

Re: Composite fields once again

Oh wow, have two weeks passed already? I seem to really suck at email... \-: Anyway, thanks for the comments. On Fri, Jun 07, 2013 at 03:55:12AM -0700, Anssi Kääriäinen wrote: > Looks like a good plan. Getting CompositeFields, multicolumn primary > keys and foreign keys to work as well as

Re: Composite fields once again

wonder if this actually works correctly for all possible primary key types in current code... > Updatable primary keys > ------ > > This feature is not directly related to the main objective of this > project, which is to implement composite fields. It is just easier for >

Re: Composite fields once again

ork is basically: > > 1. Make fields be the arbiter of what lookup types they understand. > (IntegerFields shouldn't understand "year"; maybe someone's ArrayField > subclass does understand "len".) This probably needs to be something that can > be determined on the fly

Re: [GSoC] Composite fields once again

ey understand. (IntegerFields shouldn't understand "year"; maybe someone's ArrayField subclass does understand "len".) This probably needs to be something that can be determined on the fly, as composite fields will probably need lookup types corresponding to their individ

[GSoC 2013] Composite fields: first draft of the proposal

ago. Again, for those who prefer reading the formatted version, the proposal is also available as a gist: https://gist.github.com/konk/5408673 Apologies for the huge amounts of text, I seem to have lost track while writing. Have an awesome day Michal Composite Fields, vol. 2

Re: [GSoC 2013] Composite fields: first draft of the proposal

n the future, I'm posting the full text here as well for > convenience. > > Have a nice weekend. > > Michal > > [1] https://gist.github.com/konk/5408673 > > > Composite Fields, vol. 2 > """"""""""""&quo

[GSoC 2013] Composite fields: first draft of the proposal

://gist.github.com/konk/5408673 Composite Fields, vol. 2 """""""""""""""""""""""" Aim of this project === Since I started working on this two years ago

Re: A second stab at an implementation of composite fields

t is there to make the work > on composite fields and multicolumn foreign keys in particular easier. Thanks for the overview. For the sake of completeness, we had a discussion on IRC earlier today, the outcome of which is that the ForeignObject refactor will simplify the task immensely. We also came

Re: A second stab at an implementation of composite fields

a virtual field, it doesn't have any concrete fields in the DB. There is currently zero public API support for using the ForeignObject. The addition of ForeignObject is there to make the work on composite fields and multicolumn foreign keys in particular easier. > > Another big issue to solv

Re: A second stab at an implementation of composite fields

On Fri, Apr 12, 2013 at 07:35:45AM -0700, Anssi Kääriäinen wrote: > On 12 huhti, 16:44, Michal Petrucha wrote: > ForeignKeys have been changed a lot since 2012-11-04. The introduction > of ForeignObject (which is base for ForeignKey) means that there is > support for

Re: A second stab at an implementation of composite fields

On 12 huhti, 16:44, Michal Petrucha wrote: > As far as relationship fields go, we tried to ignore them at first and > get back to them during the second half of GSoC. Two approaches were > considered, one was to special-case CompositeField targets in > ForeignKey and in

[GSoC 2013] A second stab at an implementation of composite fields

Hello everyone, Hopefully some of you still remember me as the guy who's been trying to implement support for composite primary keys by means of composite model fields. I haven't provided a whole lot of information on the progress of this project for... quite a long time, so I'll try to rectify

Re: [GSoC composite fields] Late post-GSoC check-in #1

First off, let me apologize for not reporting progress after the SoC has ended. At first I thought I'd relax for a few days, but then the work started piling up and I think anyone can guess how it went from that point on... So, again, my apologies. Second, I want to say a big thank you to the

Re: [GSoC composite fields] Weekly check-in #1

Short summary of last week: The first challenge was to make auxiliary field creation work with ForeignKey targets. The first attempt was to move parts of the model preparation mechanics to AppCache. This turned out to be a dead end because when AppCache is being populated, while importing models

[GSoC composite fields] Weekly check-in #12 (Eh, is it that late already?)

My first attempt at auxiliary field creation ended up worse than expected, it turned out I had to iron out a few other issues, like concrete model inheritance. Anyway, I also encountered a problem with ForeignKeys whose target field is also a ForeignKey. The latter has to be set up first in this

Re: [GSoC composite fields] Weekly check-in #1

The last week I've been looking into related fields and all that stuff. As it turns out, the issue is much more complex than I originally anticipated and at the moment I have some doubts whether this can be achieved as part of this GSoC. Basically, there are two approaches to the task: 1) Make

[GSoC composite fields] Weekly check-in #7

Basic support in the admin is now working: adding, editing and deleting single instances with composite primary keys. Obviously, there's no inline support yet since relationship fields are not yet ready. Michal [1] https://github.com/konk/django signature.asc Description: Digital signature

[GSoC composite fields] Weekly check-in #6

Hi folks, Sorry about this delayed post. My repo now supports using CompositeField as a model's primary key, as far as models are concerned, that means, Model.pk and friends. For the next week, expect admin to work. THe work is underway, nothing worthy of publishing just yet. Michal [1]

Re: [GSoC composite fields] Weekly check-in (this should be #5, right...?)

Hi, some visible progress on my project at long last. I spent most of the last week digging deep inside the ORM's entrails to make composite field lookups possible and finally it looks promising. While working on this I found out the extra_filters approach I intended to use was a dead end (which

[GSoC composite fields] Another weekly check-in

Another weekly update. First off, I'd like to apologize for not posting one last week; I've been completely buried under exams and other school-related stuff during the past three weeks... Things have settled now at last so I'm back at my SoC and cathing up. My repo [1] now contains support for

Re: [GSoC composite fields] Weekly check-in #1

All right, time for another check-in. This isn't a lengthy one -- unfortunately last Tuesday my laptop failed me, leaving me with no replacement, which means I have to wait for it to return from the service center to be fully up and running. In the meantime, I managed to borrow an old one a

Re: RFC: Composite fields API

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

Re: RFC: Composite fields API

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

Re: RFC: Composite fields API

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

Re: RFC: Composite fields API

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

Re: RFC: Composite fields API

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

Re: RFC: Composite fields API

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

Re: RFC: Composite fields API

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

Re: RFC: Composite fields API

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

Re: RFC: Composite fields API

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

Re: RFC: Composite fields API

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

Re: RFC: Composite fields API

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

Re: RFC: Composite fields API

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 >

Re: RFC: Composite fields API

On Thu, May 12, 2011 at 12:41 PM, Michal Petrucha <michal.petru...@ksp.sk> 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.

RFC: Composite fields API

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. This lengthy mail is mostly a recapitulation of things mentioned in the past, like [1], [2], [3

[GSoC composite fields] Weekly check-in #2

Hello again, time for the second weekly check-in. I apologize for not having posted the API as I promised yet, there's a lot of things going on in school. However, I started working on a ticket [1] as we're supposed to for the interim period. Not much else to report, hopefully the next week's

[GSoC composite fields] Weekly check-in #1

as Gregor and Jan, I created a fork on github [3] where I'll push my progress. The branch name is, surprisingly, soc2011/composite-fields. There's also the issue tracker for anyone who prefers this form of communication. In a couple days I'll hopefully post how I imagine the API with all the bloody

Re: [GSoC] Composite fields: proposal draft 2

I tried to incorporate the remarks into my proposal and I'm posting the updated parts. As usual, the full version is still available at http://people.ksp.sk/~johnny64/GSoC-full-proposal Retrieval and assignment Jacob has actually already provided a skeleton of the code

Re: [GSoC] Composite fields: proposal draft 1, full version

On Thu, Apr 07, 2011 at 03:36:52PM +0800, Russell Keith-Magee wrote: > On Thu, Apr 7, 2011 at 2:51 AM, Michal Petrucha <michal.petru...@ksp.sk> > wrote: > > GSoC 2011 Proposal: Composite Fields > > > > Hi Michal, > > This

Re: [GSoC] Composite fields: proposal, part 1

ine job describing the problem, and your solution > sounds reasonable to me as a sketch. > > But there's two things missing here for me: I'd like a description of which > query operators will be supported by composite keys. Clearly ``__exact`` would > be supported. Maybe ``__in``? But

Re: [GSoC] Composite fields: proposal, part 1

On Thu, Apr 07, 2011 at 12:38:07AM +0200, Johannes Dollinger wrote: > The only downside is that you'll have to pick a name for the index – > even if you don't really care (that's historically been a problem > with `related_name`). But anyway, since Meta.unique_together > probably cannot be

Re: [GSoC] Composite fields: proposal draft 1, full version

On Thu, Apr 7, 2011 at 2:51 AM, Michal Petrucha <michal.petru...@ksp.sk> wrote: > GSoC 2011 Proposal: Composite Fields > Hi Michal, This looks to be a fairly solid proposal. You've done a lot of detailed research, and while I'm almost comple

Re: [GSoC] Composite fields: proposal, part 1

some_field__icontains".split("__") >> - `value` is the filter argument >> - `**kwargs`: It might be necessary to pass more >>information, but certainly not arbitrary data. I >>just haven't thought that t

Re: [GSoC] Composite fields: proposal, part 1

you ain't kiddin' :) You've done a fine job describing the problem, and your solution sounds reasonable to me as a sketch. But there's two things missing here for me: I'd like a description of which query operators will be supported by composite keys. Clearly ``__exact`` would be supported. Maybe ``__

Re: [GSoC] Composite fields: proposal, part 1

` in its containing model with name > lookup_bits[0]. If such a field exists it sets up a join and > passes the resulting table alias along with lookup_bits[1:] to > f.add_lookup(). > * CompositeField checks if the first lookup bit is the name of one > of its constituent field

Re: [GSoC] Composite fields: proposal draft 1, full version

sal GSoC 2011 Proposal: Composite Fields About me My name is Michal Petrucha. I'm an undergrad student of computer science at the Faculty of Mathematics, Physics and Informatics, Comenius University, Bratislava, Slovakia. As a high school student

Re: [GSoC] Composite fields: proposal, part 1

s are implemented as virtual fields. This refactoring, which involves cleaning up (and splitting) db.models.sql.query and db.models.fields.*, would probably be full of dragons. Finding a clean public API for Field and Query alone would be major task. But it could result in a decoupled and compar

Re: [GSoC] Composite fields: proposal, part 1

post at least the part I have already written so that at least something can be commented on for now. Just to make sure there won't be any formatting issues, I uploaded it here: http://people.ksp.sk/~johnny64/GSoC-full-proposal GSoC 2011 Proposal: Composite Fields

Re: [GSoC] Composite fields

On Sun, Apr 03, 2011 at 03:08:51PM -0400, Alex Gaynor wrote: > Like Carl I haven't had time to properly read this, but one important thing > (IMO) to think about is not just having composite field support, but support > for "virtual" fields in general, that is fields that don't map to a database >

Re: [GSoC] Composite fields

On Sun, Apr 03, 2011 at 02:52:01PM -0400, Carl Meyer wrote: > I haven't had time yet to sit down and look at your implementation > questions for a CompositeField (how it works with lookups and Qs, etc), > but I do think that one design goal for a CompositeField implementation > is that we should

Re: [GSoC] Composite fields

On Sun, Apr 3, 2011 at 2:52 PM, Carl Meyer wrote: > Hi Michal, > > On 04/01/2011 09:22 PM, Michal Petrucha wrote: > > I propose to implement a CompositeField with the following properties: > > > > - will be represented as a namedtuple containing the values of the > > actual

Re: [GSoC] Composite fields

Hi Michal, On 04/01/2011 09:22 PM, Michal Petrucha wrote: > I propose to implement a CompositeField with the following properties: > > - will be represented as a namedtuple containing the values of the > actual fields it encapsulates > > - will support retrieval and assignment (assignment

[GSoC] Composite fields

://docs.djangoproject.com/en/dev/ref/models/querysets/#field-lookups the only thing I see possible is __in but that might be overly complicated if we go down the Q-object way. - CompositeField.unique would make the unique_together Meta option unnecessary - Composite fields would be encoded

  1   2   >