Re: Composite Key at Europython

ve developed using > monkey some patch because the purpose was not forking django. Is more easy > introduce a small library in a project that a fork of django itself. > > So I was preparing the paper to submit to Europython when I saw the > konk (Michal Petrucha) fork of Django, tha

[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: 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 <michal.petru...@ksp.sk> wrote: > ForeignKeys have been changed a lot since 2012-11-04. The introduction > of ForeignObject (which is base for ForeignKey) means that the

Re: A second stab at an implementation of composite fields

On Wed, Apr 17, 2013 at 03:49:11AM -0700, Anssi Kääriäinen wrote: > The basic idea is that there is a new ForeignObject class. A > ForeignObject basically just takes a related model, and from_fields > and to_fields which are the names of the fields used for the relation. > Then, the ORM knows how

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

Hello, as I promised a week ago, I'm posting a draft of my proposal. It is far from complete, specifically, it does not contain technical details on how things are going to be implemented. I'll try to fill these in as soon as possible, although I wrote more on most of them in my previous emails

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

Hello, Last week I posted a draft of a timeline for my proposed project and only afterward I realized that the timeline by itself does not convey any meaningful information without explaining each item a little bit deeper. Here comes the full version which I managed to finally complete a while

Re: first() and last(), earliest() and latest()

> > I initially modeled "first()" and "last()"'s behaviors to mimic > > "latest()", but in this new pull request, you can pass multiple field names > > into "first()" and "last()" so it behaves like "order_by()". It's more > > flexible and requires less typing, but I wonder if we should just

Re: Why apps have to have unique names? [related with subapps and name collision]

On Mon, Jun 03, 2013 at 01:04:34PM +0300, Yishai Beeri wrote: > Is this not almost trivial to work around by creating a new module > 'newapp', importing the original app code from it, and then using > 'path.to.newapp' as a new "copy" of the app in INSTALLED_APPS? Not really. At least not for

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

[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: [GSoC] Composite fields once again -- irregular status report #2

Hello, I apologize for the lack of updates on the progress of my project in the past few weeks, there just wasn't much to report, unfortunately. I spent the past two weeks porting the ForeignKey refactor on top of master. It took significantly more time to do than I anticipated due to all the

Re: Making ".only()" a bit smarter

On Fri, Jul 19, 2013 at 01:02:34PM +0100, Pablo Recio wrote: > Hi devs, > > I just came up with the following scenario: > > class A(models.Model): > # some fields... > b = models.ForeignKey(B) > > class B(models.Model): > # other fields > > A simple FK relationship. Well, then I

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

[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, the

Changes in Model._meta

Hello, As part of my GSoC work [1] I did a refactor of ForeignKey whereby I turned it into a virtual field which creates an auxiliary concrete field to hold the raw value. As part of this, there are several changes that I did in Model._meta: 1) There are now more fields in _meta.fields,

Re: Changes in Model._meta

On Sat, Aug 17, 2013 at 08:34:27AM +0700, Russell Keith-Magee wrote: > > 1) There are now more fields in _meta.fields, obviously. For each > >ForeignKey there is now an extra field with `_id` appended to its > >name. This extra field is not editable nor serializable, which > >means

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

Composite primary keys

to be focused on from the perspective of this project and those to be postponed to a later stage or with little relevance. Thanks in advance for any feedback. Michal Petrucha signature.asc Description: Digital signature

Re: Composite primary keys

some ordering since the primary key would be represented by a tuple. If you don't know for sure in which order the values are, you can't really use the .pk property. This would require a thorough explanation in the docs, that if you supply values that compare equal to primary_key, the order of fie

Re: Composite primary keys

ce you > branch out into the ecosystem you find TagFields, PickleFields (ugh) > and so forth. Just a note, my first approach at the composite ForeignKey field would fall into this category anyway. I think we can't avoid that with this kind of functionality... Michal Petrucha signature.asc Description: Digital signature

Re: Composite primary keys

ield which would have to throw exceptions left and right > for most of the common field operations. I don't see how ForeignKeys would be possible this way. Michal Petrucha signature.asc Description: Digital signature

Re: Composite primary keys

e's a way we can merge these two things together somehow? The composite index could be achieved by the standard field option Field.db_index applied to a CompositeField. This would still be consistent with the rest of the API since it would not require any new construct to do this thing. To sum up, I believe the CompositeField could be a general solution to both composite primary keys and composite indexes. Michal Petrucha signature.asc Description: Digital signature

Re: Composite primary keys

than some flavor of a tuple. And to make things like SomeModel.objects.get(pk=some_value) possible, we'd still have to implement most of the functionality of a composite field. Michal Petrucha signature.asc Description: Digital signature

[GSoC] Composite fields

be the one to choose. I, personally, like the CompositeField idea the most but I'd be also willing to implement the CompositeIndex or just plain Meta attribute if the majority chooses so. There have been voices for and against each one of them but no clear champion. Michal Petrucha signature.asc D

Re: [GSoC] Composite fields

to figure out how to do with CompositeFields. Michal Petrucha signature.asc Description: Digital signature

Re: [GSoC] Composite fields

e used to pass the actual value. Nevertheless, I'm not sure what you mean by "all the places we use metadata". Having taken a quick look at the documentation index, I don't see any relevant topic I haven't mentioned in previous e-mails, however, that doesn't mean I haven't overlooked somethin

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

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 I participated in programming contests such as the Olympiad in Informatics

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

On Wed, Apr 06, 2011 at 06:22:33AM +0200, Johannes Dollinger wrote: > > Am 06.04.2011 um 02:45 schrieb Michal Petrucha: > > [snip] > > > unique and db_index > > ~~~ > > Implementing these will require some modifications in the backend code. >

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, part 1

On Wed, Apr 06, 2011 at 04:57:39PM -0500, Jacob Kaplan-Moss wrote: > So far this looks pretty good to me. Assuming you get the rest done > with a similar level of detail I'll be voting to approve it (and > possibly signing up to mentor, time-willing). Thanks for the encouragement, I really

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

[GSoC composite fields] Weekly check-in #1

details. Just hang on those few days until I write it down. I guess this is all I have to report for tonight, more coming soon. Michal Petrucha [1] http://groups.google.com/group/django-developers/browse_frm/thread/120d401e302f369b/82471d2407c87abf [2] http://people.ksp.sk/~johnny64/GSoC-full

[GSoC composite fields] Weekly check-in #2

check-in will be richer. Michal Petrucha [1] http://code.djangoproject.com/ticket/5535 signature.asc Description: Digital signature

RFC: Composite fields API

ity directly inside CompositeField or factor it out into something more general?) I'll really appreciate each comment. Michal Petrucha [1] https://groups.google.com/forum/#!topic/django-developers/Eg1AHjAvNps [2] https://groups.google.com/forum/#!topic/django-developers/Y0aAb792cTw/discussion

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

> > 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 Tue, May 17, 2011 at 02:05:10AM -0700, akaariai wrote: > On May 12, 2:41 pm, Michal Petrucha <michal.petru...@ksp.sk> wrote: > > Due to the nature of this field type, other lookup filters than > > ``exact`` and ``in`` would have unclear semantics and won't be > > s

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

[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 (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] 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: Weekly check-in (this should be #5, right...?)

On Tue, Jul 05, 2011 at 03:39:53PM -0700, akaariai wrote: > I did a glance-over of your github branch. I was especially looking > for how you will handle LEFT OUTER JOINS involving composite primary > keys / foreign keys. If I am not missing something, I think this > haven't been done yet. I have

[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

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

Re: Weekly check-in #1

On Wed, Jul 27, 2011 at 05:05:00AM -0700, akaariai wrote: > It might be a little late to comment on this, but here is some > opinions from somebody knowing something (but not much) about the ORM. > My first feeling is that from the django/db/models/sql/query.py point > of view it doesn't matter

[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: Speed up models.Model.__init__: deprecate pre_init and post_init signals?

On Sat, Aug 13, 2011 at 07:22:54AM -0700, Anssi Kääriäinen wrote: > I am trying to speed up Model.__init__, but it seems it is pretty well > optimized already. However, there are still some things that could be > done to speed up it even further. > > Deprecate pre_init and post_init signals. I

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

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: Composite Primary Keys

On Tue, Feb 16, 2016 at 05:38:12PM -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

Re: Proposal on Custom Indexes - Google Summer of Code

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.

Re: Bringing some popular must have django tools/packages under django org umbrella

On Wed, Mar 16, 2016 at 04:06:32PM +0100, Raphaël Barrois wrote: > Hello there, > > I am not sure the tone of that discussion is suitable for that mailing-list ;) I totally agree on this point. Let's try to keep it civil. > Regarding the initial discussion, if I understand correctly, the idea

Re: relative path in {% extends "...base.html" %} like relative import

On Thu, Mar 24, 2016 at 05:06:54AM -0700, Vitaly Bogomolov wrote: > > The code seems too complicated. Could we reuse os.path handling from the > > standard library to simplify it? > > > > I don't think, that os.path is applicable in this case, because > template_name != file_name. In fact,

Re: Organizing the built-in system check framework's hint messages

On Thu, May 19, 2016 at 02:56:48PM -0700, Quentin Fulsher wrote: > Here is a super quick proof of concept that I put together. I just branched > my fork of django and added a little to it. Here is the comparing changes > page[1]. > > Quick summary of changes: I created a dictionary that would

Re: Extend support for long surnames in Django Auth

On Tue, Aug 02, 2016 at 06:09:00PM +0300, Shai Berger wrote: > Well, there's one precedent that is quite pertinent here, and that > is AUTH_USER_MODEL. But a setting for the length of a field in a > built-in app is problematic because it would imply a migration in > that app, rather than user

Re: Composite key development

SoC) > > = > > > Michal Petrucha participated in two Google Summer of Code (GSoC) projects > in 2011 and 2013, during which some extensive code, tests and documentation > were written. Unfortunately this project didn't reach the point where it > could be merged into

Re: Challenge teaching Django to beginners: urls.py

Tjena Emil, On Mon, Sep 12, 2016 at 01:32:45PM -0700, Emil Stenström wrote: > Hi Djangonauts, > > I'm just back from my second year of teaching Django to absolute beginners. > The course is a combination of HTML, CSS, Python, and Django, and after > five days of coding they have a real live

Re: is_valid as property

Hi everybody, On Fri, Sep 30, 2016 at 09:04:32AM +0300, Shai Berger wrote: > Hi Sven, > > On Thursday 29 September 2016 22:09:27 Sven R. Kunze wrote: > > > > Am Donnerstag, 29. September 2016 20:26:54 UTC+2 schrieb Aymeric Augustin: > > > > > Generally speaking, properties are expected to be

Re: DEP pre-proposal for a simpler URLs syntax.

On Tue, Oct 04, 2016 at 09:21:33AM -0700, Tom Christie wrote: > > The only technical reason I see for enforcing the starting slash > > The leading slash in the syntax is open to discussion, however I'm very > strongly in favor due to two points: > > * It is a strong and consistent visual

Re: does anyone use models with underscores in the name?

On Mon, Oct 03, 2016 at 09:30:44AM -0700, Tim Graham wrote: > Ticket #27295 notes that the ORM doesn't work well with models that start > with an underscore (e.g. _UsersGroup). I didn't check if the same problem > exists with an underscore anywhere in the name, but I wanted to ask if > anyone

Re: Challenge teaching Django to beginners: urls.py

On Thu, Sep 15, 2016 at 12:56:16AM -0700, Sjoerd Job Postmus wrote: > I'm not sure if I agree. > > On the one hand I would like to say: > > "I agree. For instance, if the type is `hex`, it would be really weird if > it were to be cast to an int. For `uuid`, would you expect a `UUID` >

Re: is_valid as property

On Tue, Oct 11, 2016 at 04:28:40PM +0200, ludovic coues wrote: > First time you access form.errors, it will call form.full_clean. > > But after looking at the code and not simply reading the doc, I agree > that is_valid should be a property. After the first call to is_valid, > the value won't

Re: (contrib.admin) Improving object deletion

Marcin Nowak skrev: (14 oktober 2016 15:08:15 CEST) >Hi all. > >Sometimes there is huge amount of related objects. In the effect there >is >no possibility to delete a model because of http timeout error. >Displaying objects to be deleted is quite nice feature, but just

Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Apr 02, 2019 at 04:41:36AM -0700, Sage M.A. wrote: > Hello, everyone! My name is Sage. I'm a 19-year-old computer science > student from Indonesia. I'm planning to join the Google Summer of Code > (GSoC) this year, and I want to contribute

Re: injecting settings

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi folks, On Tue, May 07, 2019 at 10:53:37PM +0200, Aymeric Augustin wrote: > If we're only talking about providing default values for settings, currently > there are two straightforward solutions: > > 1. Like Adam suggested, access settings like