Re: We're a group of students at UC Berkeley looking to contribute to Django

[shacker]

Since you're at Berkeley, stop by the Graduate School of Journalism some 
time to see the Django sites we run and meet the devs (look me up). Would 
also be interested in campus Django meetings (any alternative to the 
relentless Drupal push on campus :).

./s

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/QC0sasjCOQsJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: We're a group of students at UC Berkeley looking to contribute to Django

[Jeremy Dunck]

On Wed, Sep 28, 2011 at 3:36 AM, Paul McMillan  wrote:
> I'm Paul, one of the core devs for Django. I'm curious which class
> you're enrolled in and what your requirements are. I'm always excited
> to see new people looking to get involved in the project, and I happen
> to be VERY local.

Hi Paul & Berkeley people.  I'm newly in the SF area.

If you want to meet up for a sprint some time, that would be sweet.

Paul, are you active in any local Python/Django user groups?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: We're a group of students at UC Berkeley looking to contribute to Django

[Paul McMillan]

Hi Jamin,

I'm Paul, one of the core devs for Django. I'm curious which class
you're enrolled in and what your requirements are. I'm always excited
to see new people looking to get involved in the project, and I happen
to be VERY local. If you wanted to meet up some evening in one of the
libraries or a coffee shop, I'd be very happy to help you guys get
started (and I can help you find some non-trivial ways to dive into
the codebase and make real contributions even without being familiar
with the whole codebase).

Drop me an email (and feel free to CC whoever else you're working
with), or send me a text - 510 717 1471.

-Paul

On Mon, Sep 26, 2011 at 8:10 PM, jaminw  wrote:
> Hi all,
> We're a a group of students at UC Berkeley taking an open source class and
> we've decided to contribute to Django.
> We looked at the bug tracker but it seems a little disorganized and some of
> the easier bug reports are kinda trivial.
> Is there any suggestions on how do we start?
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/p2sX1LUo6K0J.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: We're a group of students at UC Berkeley looking to contribute to Django

[Paul McMillan]

Alec,

I'm glad you're excited about this issue, but let's keep discussion of
the installation issue on the other thread (and/or the ticket
tracker). It would be best if we didn't go tasking new volunteers with
big projects the community hasn't agreed on.

The ticket tracker, and the issues there, and the contributing guides,
are a great place for these folks to start.

-Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: prefetch_related - new feature suggestion

[Johannes Dollinger]

Am 27.09.2011 um 05:18 schrieb Luke Plant:

> On 27/09/11 03:23, Alex Gaynor wrote:
> 
>> I'm not a fan of this, for a few reasons, firstly: because it feels
>> wrong for a QuerySet to execute multiple queries.  This isn't a deal
>> breaker, just something that struck my conceptually initially.  Second I
>> disagree that it's difficult to do outside of core, it's not as easy as
>> it ought to be, but it's very possible (citation: I've done it :)).
> 
> Would you like to share your solution? I found it pretty difficult to
> come up with anything that:
> 
> 1) could be done on a per-query basis and
> 2) didn't require changes to the code that would use the QuerySet
> objects i.e. fully API compatible.

I don't believe (2) is an important requirement. It may even be 
counter-productive.
For me, the ideal solution would allow to filter or annotate the prefetched 
QuerySet – and thus, obj.relmanager.all() would be a bad API to access the 
prefetched objects.
I'd like to propose something that works more like annotations:

>>> 
Foo.objects.prefetch_related(related_list=Foo.related_objects.filter(x__gt=42))

This would require related object descriptors to return something like a 
ParametrizedQuerySet object when accessed via the model class, e.g.:

>>> Foo.related_set.filter(x__gt=42).apply(*foo_objects)
# equivalent to: Related.objects.filter(foo__in= 
foo_objects).filter(x__gt=42)

Or, simpler, but less generic:

>>> Foo.related_set.filter(x__gt=42)
'foo', Related.objects.filter(x__gt=42)

This syntax would also make it somewhat obvious that you're going to use more 
than one db query.
Finally, and to support Alex point, if you drop your second requirement, it's 
well possible to implement this (modulo my proposed API) with the public 
QuerySet API + some introspection.

__
Johannes

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

[NoSQL] Sub-object queries / refactoring JOIN syntax into model fields

[Jonas H.]

Hallöchen,

some non-relational databases (e.g. MongoDB) have support for 
arbitrarily nested objects. To make queries that "reach" into these 
sub-objects, the Django-nonrel developers find it appealing to use JOIN 
syntax. For instance, if you had this person in your database


  {'name': 'Bob', 'address': {'city': 'NY', 'street': 'Wall Street 42'}}

you could find Bob using these queries:

  Person.objects.filter(name='Bob')
  Person.objects.filter(address__city='NY')
  Person.objects.filter(address__street__startswith='Wall')
  ...

Similarly, sub-objects may be stored in a list, like so:

  {
'votes': [
  {'voter': 'Bob', 'vote': 42},
  {'voter': 'Ann', 'vote': 3.14}}
]
  }

  Vote.objects.filter(votes__vote__gt=2)
  ...


These sub-object queries are essential for non-relational databases to 
be really useful so this is an important feature.


What's the core team's opinion on this topic -- is there any chance to 
get something like that into Django at all? (Maybe you think two 
meanings for one syntax cause too much confusion)


Secondly, how could this be implemented? I thought about refactoring 
JOIN syntax handling into the model fields (as little logic as required; 
refactoring the actual hardcore JOIN generation code seems like an 
impossible task for anyone but the original author)... any other ideas?


So far,
Jonas

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: prefetch_related - new feature suggestion

[Peter]

I'd just like to chime in to say this should definitely be part of
core - it's a common requirement, and whilst it could be a third party
app, it certainly feels much more at home in core.

On Sep 27, 1:13 pm, Luke Plant  wrote:
> For me, QuerySet is at a level of abstraction where I don't think it
> guarantees a single query. We have quite a bit of precedent here I think:

I also agree on this - many ORMs give the option to fetch objects
using a separate select (I'm thinking for example hibernates
"FetchMode.SELECT"). I think if you explicitly use this then you
probably need to understand what it does like anything else.

I've only had a brief look at the patch, but no doubt even if it needs
some polish it'll be a good start!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: prefetch_related - new feature suggestion

[Luke Plant]

Hi Alex,

Just replying to your other objections, now I've had some time to think
about them:

On 27/09/11 03:23, Alex Gaynor wrote:

> I'm not a fan of this, for a few reasons, firstly: because it feels
> wrong for a QuerySet to execute multiple queries.  This isn't a deal
> breaker, just something that struck my conceptually initially.

For me, QuerySet is at a level of abstraction where I don't think it
guarantees a single query. We have quite a bit of precedent here I think:

 - some methods produce new QuerySets that only execute queries
   when you iterate over them.

 - some methods execute queries immediately, like get(), exists() and
   count(), and *some* slicing operations.

 - of the latter type, some are optimised to *not* to do queries if
   we can get the answer from the result cache. (This is not even
   explicitly documented).

So I think QuerySet is at a level where it is expected to give you some
more intelligent, optimised tools for executing queries. The actual
number of queries executed is non-trivial to work out by looking at the
code in front of you, but the documentation, combined with analysis of
how the QuerySet was built will give you an upper bound.

You can also consider select_related() in this light - code as simple as
'map(unicode, queryset)' can do 1 query or N queries, depending on how
the QuerySet was constructed.

>  Finally (for now ;)) it doesn't feel right for something inside core to
> have caveats like "only works if you use .all()", there's a very good
> technical reason for this, but something about it is irking me the wrong
> way.

The 'only works if you use all()' bit is nothing other than the normal
behaviour of QuerySets - if you evaluate one QuerySet and fill its
result cache, those results will not be used by any QuerySets based off
the first via filter() etc. I probably worded it badly. In the
implementation, I only modified the RelatedManager.all() methods because
if you are doing anything else, you will end up with a clone that has an
unfilled QuerySet anyway (if I'm thinking correctly), which is
presumably what you want if you do that.

For me, the most annoying limitation is the 'single depth' thing. I
think it is entirely possible to extend this work and fix that, but that
can be added later as an enhancement and the single level version is a
useful enough optimisation in its own right.

Regards,

Luke

-- 
"I spilled spot remover on my dog. Now he's gone." (Steven Wright)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: prefetch_related - new feature suggestion

[koenb]

On 27 sep, 05:18, Luke Plant  wrote:
> On 27/09/11 03:23, Alex Gaynor wrote:
>
> Would you like to share your solution? I found it pretty difficult to
> come up with anything that:
>
> 1) could be done on a per-query basis and
> 2) didn't require changes to the code that would use the QuerySet
> objects i.e. fully API compatible.
>
> The one avenue I didn't explore yet was proxying the entire model
> instance, which I'm sure would work, but could have lots of annoying
> corner cases with Python magic methods etc.
>
> Luke
>

I once created django-selectreverse [1] to do something alike, but
that did require changing your code (no API compat.) and was also
somewhat limited.

It would be very nice to have something in core for this.

Koen

1: http://code.google.com/p/django-selectreverse/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: We're a group of students at UC Berkeley looking to contribute to Django

[Alec Taylor]

Great to hear you're getting involved!

Some things I'd like implemented in DJango involve reducing
build-setup environment and expanding project uses to the CMS markets
by incorporated DJango project distribution+setup.

For starters, I was thinking 3 installers (exe,rpm,deb) and a shell
script (sh), but eventually building a small website around DJango for
setups.

Steps
- Download python
- Install python (set location)
- Download django
- Install django (set location + perhaps select db info?)
- Download project (perhaps pick from list?)
- Install project
- Option to run project + run readme

I'm currently too distracted by the actual project I want to
distribute to do this on my own.

If a few of you are interested though, I can give you tips+guidance to
get started. :]

All the best,

Alec Taylor

On Tue, Sep 27, 2011 at 1:10 PM, jaminw  wrote:
> Hi all,
> We're a a group of students at UC Berkeley taking an open source class and
> we've decided to contribute to Django.
> We looked at the bug tracker but it seems a little disorganized and some of
> the easier bug reports are kinda trivial.
> Is there any suggestions on how do we start?
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/p2sX1LUo6K0J.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: API for introspecting models

[Mathieu AGOPIAN]

Hello (again),

seems my previous message got eaten up, so I'll try a repost :

I've done a small app that I use to inspect models, it lives here: 
https://github.com/magopian/django-inspect-model

I'm afraid this isn't rocket science, and is probably very ugly. I'm using 
the "inspect" module from the python stdlib.

Please feel free to comment on my piece of crap^Wcode and let me know if 
there's anything that could help or if I need to tweak/modify anything to 
make it useful.

Regards

Mathieu

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/p5usIzkHPjAJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.