Re: Django-nonrel patches

2012-06-26 Thread Jonas H. 

On 06/26/2012 11:07 PM, Adam "Cezar" Jenkins wrote:

Last I heard Jonas wanted to do a new release of mongodb-engine. He might
have meant to say he was not maintaining the project anymore, but he's not
the only one with commit access.


The main thing is that I've lost interest in maintaining this huge 
project on my own -- and to be honest, there haven't been too many 
code/documentation contributions since the GitHub migration.


I tried to do a new MongoDB Engine release for a few times but every 
time something got in my way (like Travis not working, University, ...). 
Not too much support from other people here either.


I'm not blaming anyone here. It's just the current state of things.


In terms of the fundamental "MongoDB vs. ORM" debate, here are my 2 
cents: It's okay if we only get to work 70% of the ORM and apps -- 
that's already a huge benefit for people working with MongoDB and 
Python.  Most apps don't use JOINs or could get rid of them with only a 
handful of simple changes.


Cheers :-)
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: Django-nonrel patches

2012-06-26 Thread Adam "Cezar" Jenkins 
On Tue, Jun 26, 2012 at 4:11 PM, Chris Northwood wrote:

>
> Surely that's what it needs though, an 'ORM' and an 'Object-Document
> Mapper' at some point. What's the advantage of trying to shoehorn
> MongoDB to work with an ORM, when it's not relational, and as it has
> to be hidden behind the same abstraction layer as a RDBMS, you lose
> the benefits of it being non-relational?
>
>
In my experience, a good bit of your document will map over to relational
just fine, and vice versa. There is a lot of similarities between a
ManyToMany and a list of foreign keys. The intersection of relational and
non-relational, at least with Mongo, is pretty large. Of course with other
non-relational DBs (admittedly a large variety of DBs) you milage will
vary.

Even if you look at the libraries like mongoengine, the documents and API
are similar to the ORMs.

Remember that mongo has foreignkeys in the form of objectids.



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

-- 
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: Django-nonrel patches

2012-06-26 Thread Luciano Pacheco 
On Jun 27, 2012 7:12 AM, "Chris Northwood"  wrote:
>
> On 26 June 2012 22:07, Adam "Cezar" Jenkins 
wrote:
>
> > I have to agree, that's the big one. Though I the ecosystem of 3rd party
> > apps is what makes using Django so great. If there is one ORM for  99%
of
> > the apps out there, and only one that works Mongo, then the only real
use
> > case of Django is going to be a system where you're using a RDBM
> > in combination with Mongo.
>
> Surely that's what it needs though, an 'ORM' and an 'Object-Document
> Mapper' at some point. What's the advantage of trying to shoehorn
> MongoDB to work with an ORM, when it's not relational, and as it has
> to be hidden behind the same abstraction layer as a RDBMS, you lose
> the benefits of it being non-relational?

I agree that they are 2 different concepts (ORM and documents), however the
namings in Django API looks like it might work well even for handling
documents <=> objects.

User.objects.all()
User.objects.filter(email=email)

Looking at this there is nothing telling about the relational concepts
behind it.

Of  course for all relations operations (foreings, many to many, etc) the
api might start to differ .

If Django has a support for the basic api but with admin and loging working
I think is a good step forward. After that we can wait for a better common
sense about relations between documents emerge. We have been waiting this
common sense to emerge without any builtin support, maybe with the basic
api would have more people involved with.

[].

Luciano Pacheco

-- 
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: Django-nonrel patches

2012-06-26 Thread Chris Northwood 
On 26 June 2012 22:07, Adam "Cezar" Jenkins  wrote:

> I have to agree, that's the big one. Though I the ecosystem of 3rd party
> apps is what makes using Django so great. If there is one ORM for  99% of
> the apps out there, and only one that works Mongo, then the only real use
> case of Django is going to be a system where you're using a RDBM
> in combination with Mongo.

Surely that's what it needs though, an 'ORM' and an 'Object-Document
Mapper' at some point. What's the advantage of trying to shoehorn
MongoDB to work with an ORM, when it's not relational, and as it has
to be hidden behind the same abstraction layer as a RDBMS, you lose
the benefits of it being non-relational?

Chris

-- 
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: Django-nonrel patches

2012-06-26 Thread Adam "Cezar" Jenkins 
Note that I've talked about the issues that nonrel has, and there are many.
That said, I have some responses below. I'm not trying to be the nonrel
spokesperson.

On Tue, Jun 26, 2012 at 3:34 PM, Daniel Greenfeld  wrote:

>
> I don't mean to pick bones, but looking at the github account, BETA
> apparently means being a port with stern warnings about not using it right
> now.
>

It's not tested enough for production yet, no. Though there are those
testing it right now, at least on AppEngine. On the thread I link later on
you can see the discussion.


>
>
>> 2. django-nonrel is unsupported. It switched maintainers and the
>>> current maintainer is not working on it.
>>
>> Django-nonrel is very much maintained. Look at the github
>> https://github.com/**django-nonrel/ 
>>
>>
> This does not match what someone claiming to be the current lead
> maintainer said to me personally after my talk in front of dozens at
> DjangoCon Europe.
>
> While I understand this sort of misinformation I may have spread is
> annoying to you, imagine how it comes to the rest of us when project
> leadership is not clear.
>

Jonas is hesitant to lead the project, and I understand where he's coming
from. For a long time there were only Mongo people maintaining the project.
In a project where 80% of the users are using it for AppEngine, that can be
a problem for hammering out bugs.

If you look at the thread at
https://groups.google.com/forum/?fromgroups#!searchin/django-non-relational/1.4/django-non-relational/_OFjwuPjc88/iqLqnEGauNwJyou'll
see there are people doing active development on non-relational.

Last I heard Jonas wanted to do a new release of mongodb-engine. He might
have meant to say he was not maintaining the project anymore, but he's not
the only one with commit access.



>
> 1. http://django-nonrel.readthedocs.org lacks any sort of
> team/contributor listings.
> 2. https://github.com/django-nonrel/mongodb-engine/blob/master/AUTHORS.rsthas 
> people in it who may no longer maintain it.
>
> What's going on? What can django-nonrel do to make it much more clear to
> everyone who is involved and who is the actual leadership?
>

There's a big documentation issue. It's known. Migration for All Button
Pressed to the new "rag tag" team is slow, but I'm sure it'll get there.


>
>> I have to agree with you here. The nature of the Django ORM makes
>> anything like this a hack. Not much choice in that regard.
>>
>> I've wondered if it's possible to make an ORM that API compatible with
>> forms/admin/etc that doesn't hack onto the existing ORM?
>>
>>>
>>> In my humble opinion, the answer is no. ORM is for mapping objects onto
> relational databases, and the entire API is designed around that concept.
> MongoDB is a Document store and should be handled differently.
>  Django-nonrel adds a lot of magic, not necessarily in code, but in API
> design. It turns non-relational databases into relational databases, IMO
> removing many of the advantages of those systems for little gain except for
> in early speed of development.
>
> The trick is, as I believe others have raised, is how to get Admin and
> Forms and other things in Django to work with MongoDB. :-)
>

I have to agree, that's the big one. Though I the ecosystem of 3rd party
apps is what makes using Django so great. If there is one ORM for  99% of
the apps out there, and only one that works Mongo, then the only real use
case of Django is going to be a system where you're using a RDBM
in combination with Mongo.


>
> Danny Greenfeld
>
>>  --
> 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/-/VktFJetdkWIJ.
>
> 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: Django-nonrel patches

2012-06-26 Thread Daniel Greenfeld 


On Sunday, June 24, 2012 10:31:41 PM UTC+8, Cezar Jenkins wrote:
>
> I'm only lightly involved in the project, but there is some misinformation 
> going around about it.
>
> On Sun, Jun 24, 2012 at 5:47 AM, Daniel Greenfeld  
> wrote:
>
>>
>>
>> We evaluated django-nonrel for use in projects and looked again at
>> django-nonrel for our talk at DjangoCon Europe. To summarize our
>> findings and opinions:
>>
>> 1. django-nonrel is stuck on Django 1.3, which has some security 
>> implications. 
>
> 1.4 support is implemented and being tested in a beta mode right now.
>

I don't mean to pick bones, but looking at the github account, BETA 
apparently means being a port with stern warnings about not using it right 
now.
 

> 2. django-nonrel is unsupported. It switched maintainers and the
>> current maintainer is not working on it.
>
> Django-nonrel is very much maintained. Look at the github 
> https://github.com/django-nonrel/
>  
>
This does not match what someone claiming to be the current lead maintainer 
said to me personally after my talk in front of dozens at DjangoCon Europe. 

While I understand this sort of misinformation I may have spread is 
annoying to you, imagine how it comes to the rest of us when project 
leadership is not clear. 

1. http://django-nonrel.readthedocs.org lacks any sort of team/contributor 
listings.
2. https://github.com/django-nonrel/mongodb-engine/blob/master/AUTHORS.rst 
has people in it who may no longer maintain it.

What's going on? What can django-nonrel do to make it much more clear to 
everyone who is involved and who is the actual leadership?

>
> I have to agree with you here. The nature of the Django ORM makes anything 
> like this a hack. Not much choice in that regard.
>
> I've wondered if it's possible to make an ORM that API compatible with 
> forms/admin/etc that doesn't hack onto the existing ORM?
>
>>
>> In my humble opinion, the answer is no. ORM is for mapping objects onto 
relational databases, and the entire API is designed around that concept. 
MongoDB is a Document store and should be handled differently. 
 Django-nonrel adds a lot of magic, not necessarily in code, but in API 
design. It turns non-relational databases into relational databases, IMO 
removing many of the advantages of those systems for little gain except for 
in early speed of development.

The trick is, as I believe others have raised, is how to get Admin and 
Forms and other things in Django to work with MongoDB. :-)

Danny Greenfeld

>

-- 
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/-/VktFJetdkWIJ.
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: QuerySet refactoring

2012-06-26 Thread Steven Cummings 
That answers my question. Thanks! Perhaps I'll try to make
matched-vs-updated a point of discussion for Django 2.0. As for the other
stuff, I'll give consideration to work on save_base and maybe work up a
proposal there.
--
Steven


On Tue, Jun 26, 2012 at 2:31 AM, Anssi Kääriäinen
wrote:

> On 26 kesä, 08:41, Steven Cummings  wrote:
> > Sorry for chiming in so late. I very much like the goals of this effort,
> > particularly bringing clarity to some of the internal APIs. Some related
> > points for your consideration:
>
> No problem. I have been so busy lately that I haven't gotten a single
> commit done... Things look a bit calmer, so I hope I will be able to
> start working on Django again.
>
> > * Would the rows matched vs. updated issue be resolved or clarified in
> this
> > effort [1]?
>
> I don't believe this one can be changed. Django currently returns rows
> matched, and to remain backwards compatible a flag to .update() would
> be needed. The flag would change the return value from matched to
> changed rows. This doesn't feel right.
>
> > * It seems like the work I had started to expose accurate update/delete
> > counts [2], and further provide the capability for conditional updates
> and
> > deletes [3] would be more clearly done on the basis of such a refactor.
> > Does that seem accurate to you or will it not make much of a difference
> > there?
>
> For the optimistic concurrency control for model .save(), it seems
> that splitting the save_base() to smaller parts could allow subclasses
> to do whatever needed for good optimistic concurrency control. Another
> option is some sort of hook which allows the instance to add
> additional conditions to the save.
>
> I must note that the idea of the refactor is not to do any drastic
> rewrites. The structure of the ORM will stay mostly the same.
> Currently my aim is at the add_q/add_filter stage of the ORM, and I
> don't see much cross section with what you are doing at this stage. I
> don't have any long term plans of where this all is going, it is just
> cleanup/bugfixing of existing code. Most likely the save_base() will
> need some refactoring too.
>
>  - Anssi
>
> --
> 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.
>
>

-- 
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: cache middleware on multi sites...

2012-06-26 Thread sergey 
I create my own slightly changed cache middleware (replace get_full_path to 
build_absolute_uri)
http://macrotoma.blogspot.com/2012/06/custom-multisite-caching-on-django.html
 

четверг, 19 ноября 2009 г., 13:16:52 UTC+2 пользователь jens написал:
>
> There exist some "intersection" on multi site installation, if i use 
> django.middleware.cache.UpdateCacheMiddleware and 
> django.middleware.cache.FetchFromCacheMiddleware 
>
> Problem: 
> The cache key would be only generated based on the url without the 
> domain name. So if the page /foobar/ exist on site A and site B but 
> with different content, they would be only caches one time. 
>
> Solutions: 
> 1. The user can insert this into his settings: 
> CACHE_MIDDLEWARE_KEY_PREFIX = "FooBar %s" % SITE_ID 
>
> 2. Django should insert the SITE_ID into cache key. e.g. in 
> django.utils.cache.get_cache_key() 
>
> 3. Django should use the complete path to build the cache key. e.g.: 
> use request.build_absolute_uri() in 
> django.utils.cache._generate_cache_header_key() instead of iri_to_uri 
> (request.path) 
>
> Mfg. 
>
> Jens Diemer 
>
>

-- 
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/-/2mh_p3Uihp0J.
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: Customizable Serialization check-in

2012-06-26 Thread Tom Christie 
> default deserialized_value don't returns anything. It sets the field 
value.

Cool, that's exactly what I meant.

> but declaring function only to say "do nothing" isn't good solution for 
me.

 Declaring a method to simply 'pass' seems fine to me if you want to 
override it to do nothing.

> It is the way I am doing deserialization - pass instance to subfields

Seems fine.  It's worth keeping in mind that there's two ways around of 
doing this.

1. Create an empty instance first, then populate it with the field values 
in turn.
2. Populate a dictionary with the field values first, and then create an 
instance using those values.

The current deserialization does something closer to the second.
I don't know if there's any issues with doing things the other way around, 
but you'll want to consider which makes more sense.

> Where I returned (native, attributes) I will return (native, metainfo). 
It's only matter of renaming but metainfo will be more than attributes.

Again, there's two main ways around I can think of for populating metadata 
such as xml attributes.

1. Return the metadata upfront to the renderer.
2. Include some way for the renderer to get whatever metadata it needs at 
the point it's needed.

This is one point where what I'm doing in django-serializers differs from 
your work, in that rather than return extra metadata upfront, the 
serializers return a dictionary-like object (that e.g. can be directly 
serialized to json or yaml), that also includes a way of returning the 
fields for each key (so that e.g. the xml renderer can call 
field.attributes() when it's rendering each field.)

Again, you might decide that (1) makes more sense, but it's worth 
considering.

As ever, if there's any of this you'd like to talk over off-list, feel free 
to drop me a mail - t...@tomchristie.com

Regards,

  Tom

On Wednesday, 20 June 2012 16:28:51 UTC+1, Piotr Grabowski wrote:
>
>  W dniu 20.06.2012 13:50, Tom Christie pisze:
>  
>
> > deserialized_value function with empty content
>
> Are you asking about how to be able to differentiate between a field that 
> deserializes to `None`, and a field that doesn't deserialize a value at 
> all? 
>
> No :) I had this problem before and I managed to resolve it - default 
> deserialized_value don't returns anything. It sets the field value.
> def deserialized_value(self, obj, instance, field_name):
> setattr(instance, field_name, obj)
>
> It is the way I am doing deserialization - pass instance to subfields, 
> retrieve it from them (should be same instance, but in specific cases eg. 
> immutable instance, I can imagine that another instance of same class is 
> returned)  and return it.
>
> If I don't declare deserialized_value function then function from base 
> class is taken. It's expected behavior. So how to say "This field shouldn't 
> be deserialized".  Now I declare:
> def deserialized_value(self, obj, instance, field_name):
> pass
> For true, I can do anything in this function excepting set some value to 
> instance, but declaring function only to say "do nothing"  isn't good 
> solution for me.
>
>  
> > I changed python datatype format returned from serializer.serialize 
> method.  Now it is tuple (native, attributes)
>
>  I'm not very keen on either this, or on the way that attributes are 
> represented as fields.
> To me this looks like taking the particular requirements of serializing to 
> xml, and baking them deep into the API, rather than treating them as a 
> special case, and dealing with them in a more decoupled and extensible way.
>
>  For example, I'd rather see an optional method `attributes` on the 
> `Field` class that returns a dictionary of attributes.  You'd then make 
> sure that when you serialize into the native python datatypes prior to 
> rendering, you also have some way of passing through the original Field 
> instances to the renderer in order to provide any additional metadata that 
> might be required in rendering the basic structure.
>
>  Wiring up things this way around lets you support other formats that 
> have extra information attached to the basic structure of the data.  As an 
> example use-case - In addition to json, yaml and xml, a developer might 
> also want to be able to serialize to say, a tabular HTML output.  In order 
> to do this they might need to be able attach template_name or widget 
> information to a field, that'd only be used if rendering to HTML.
>
>  It might be that it's a bit late in the day for API changes like that, 
> but hopefully it at least makes clear why I think that treating XML 
> attributes as anything other than a special case isn't quite the right 
> thing to do.  - Just my personal opinion of course :)
>  
>  
>  Regards,
>
>Tom
>
>  
> You right that I shouldn't treated attributes so special. I have idea how 
> to fix this. Where I returned (native, attributes) I will return (native, 
> metainfo). It's only matter of renaming but metainfo will be more

Re: QuerySet refactoring

2012-06-26 Thread Anssi Kääriäinen 
On 26 kesä, 08:41, Steven Cummings  wrote:
> Sorry for chiming in so late. I very much like the goals of this effort,
> particularly bringing clarity to some of the internal APIs. Some related
> points for your consideration:

No problem. I have been so busy lately that I haven't gotten a single
commit done... Things look a bit calmer, so I hope I will be able to
start working on Django again.

> * Would the rows matched vs. updated issue be resolved or clarified in this
> effort [1]?

I don't believe this one can be changed. Django currently returns rows
matched, and to remain backwards compatible a flag to .update() would
be needed. The flag would change the return value from matched to
changed rows. This doesn't feel right.

> * It seems like the work I had started to expose accurate update/delete
> counts [2], and further provide the capability for conditional updates and
> deletes [3] would be more clearly done on the basis of such a refactor.
> Does that seem accurate to you or will it not make much of a difference
> there?

For the optimistic concurrency control for model .save(), it seems
that splitting the save_base() to smaller parts could allow subclasses
to do whatever needed for good optimistic concurrency control. Another
option is some sort of hook which allows the instance to add
additional conditions to the save.

I must note that the idea of the refactor is not to do any drastic
rewrites. The structure of the ORM will stay mostly the same.
Currently my aim is at the add_q/add_filter stage of the ORM, and I
don't see much cross section with what you are doing at this stage. I
don't have any long term plans of where this all is going, it is just
cleanup/bugfixing of existing code. Most likely the save_base() will
need some refactoring too.

 - Anssi

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