Re: Introducing ModelView, a RESTful class-based view of your resources
Hi Clement, Have a look in the django-rest-interface examples [1] they cover this exactly. You can do what you want by sub-classing Collection. [1] http://code.google.com/p/django-rest-interface/source/browse/trunk/django_restapi_tests/examples/custom_urls.py regards Matthew On Jun 20, 12:15 am, tifosi <[EMAIL PROTECTED]> wrote: > Hi David, > > Thank for your code and the repository, I use the django-rest-interface and > it's good news, that someone continue the job. > > I would like to get nested resources (e.g.: /articles/1/comments/ or > /user/username/jobs/) and the problem is that you have to pass statically > the queryset. I think I can use a decorator but I don't know how I can do > this. Do you have a suggestion? > > Regards > > Clément > > (Sorry for my English, I'm French) > > -- > View this message in > context:http://www.nabble.com/Introducing-ModelView%2C-a-RESTful-class-based-... > Sent from the django-developers mailing list archive at Nabble.com. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Experimental Git repository available
On Jun 20, 3:21 am, "Waylan Limberg" <[EMAIL PROTECTED]> wrote: > On Thu, Jun 19, 2008 at 1:52 PM, Alexander Solovyov > > <[EMAIL PROTECTED]> wrote: > > > On Thu, Jun 19, 2008 at 8:09 PM, Jacob Kaplan-Moss > > <[EMAIL PROTECTED]> wrote: > >> Yeah, hgsvn is one-way, > > > H > > >>hg help convert > > hg convert [OPTION]... SOURCE [DEST [REVMAP]] > > > Convert a foreign SCM repository to a Mercurial one. > > True, but that doesn't address pushing changes back to SVN, at least > not practically. Mercurial's own docs [1] admit this is a problem > needing improvement. Compare that with git-svn's dcommit command [2]. Actually there is an hgpushsvn included with the hgsvn package. As far as I tested it is working. I'm not sure why it isn't in the hgsvn docs, but I guess it is not tested well enough yet. -- Jeffrey Gelens --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Support for ON DELETE and ON UPDATE in foreign keys
I've implemented some code already to de-reference (SET_NULL) on
delete, in a view which first presents a list of objects which will be
deleted and a list of objects which will be de-referenced. It might
not be the most efficient approach, but it could be a starting point.
def _clear(instance):
"""
recursively clear related models before deleting `instance`.
"""
cleared = []
deleted = []
for related_set in (getattr(instance, elem) for elem in dir(instance)
if re.search(r'_set$', elem)):
if hasattr(related_set, 'clear'):
cleared.extend(elem for elem in related_set.all())
related_set.clear()
elif hasattr(related_set, 'all'):
for related_instance in related_set.all():
_cleared, _deleted = _clear(related_instance)
deleted.extend(_deleted)
return cleared, ((instance, deleted), )
@user_is_authenticated()
@request_passes_test(lambda r: r.user.is_superuser)
@transaction.commit_manually
def delete(request, app_label, model_name, pk, template='base/
delete.html', next='/base/'):
try:
model = get_model(app_label, model_name)
instance = model.objects.get(pk=pk)
except model.DoesNotExist:
raise Http404
if request.method == 'POST':
alert = '%s successfully deleted.' % instance
_clear(instance)
instance.delete()
transaction.commit()
# set alert and redirect.
context = RequestContext(request, {
})
request.session['alert'] = alert
request.session['alert_class'] = 'good'
return HttpResponseRedirect(context['base']['next'] or next)
cleared, deleted = _clear(instance)
transaction.rollback()
# set context and render template.
context = RequestContext(request, {
'cleared': cleared,
'deleted': deleted,
})
return render_to_response(template, context)
One other thing that you might need to consider is how any change here
will affect post_delete and post_save triggers. Will they still fire
when a supported database executes a cascading delete or SET_NULL, or
will they only fire when a delete/update is implemented through the
Django ORM?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Experimental Git repository available
On 19 Jun 2008, at 6:07 pm, Jacob Kaplan-Moss wrote: > If you know the correct incantation to add other git-svn-created > branches, feel free to school me :) I think Brian Rosner covered pulling in all branches from svn on his screencast about django and git [0] but I can't off the top of my head remember how he did it. http://oebfare.com/blog/2008/jan/23/using-git-django-screencast/ -- David Reynolds [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Experimental Git repository available
On Thu, Jun 19, Jacob Kaplan-Moss wrote: > On Thu, Jun 19, 2008 at 11:55 AM, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > Is this only going to offer the trunk branch? > > Until I learn more about Git, yes :) > > If you know the correct incantation to add other git-svn-created > branches, feel free to school me :) I use git-svnimport, which provides only one-way conversion from svn to git. It converts all branches. But it's going to be deprecated ... Anyway, I use it, and I sync hourly from svn. It's available at git://git.spieleck.de/django Please send me an email if you plan to use it regularly. Michael --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Support for ON DELETE and ON UPDATE in foreign keys
Russell Keith-Magee wrote: > On Thu, Jun 19, 2008 at 11:00 PM, Michael Glassford > <[EMAIL PROTECTED]> wrote: >> Now for one of the reasons that I've been trying to get the Django unit >> tests running: I'm interested in submitting a patch that adds some ON >> DELETE and ON UPDATE support in Django. But first, I want to see what >> interest there is in such a patch. > > I'm certainly interested in supporting ON DELETE and ON UPDATE, and > from a surface inspection, you appear to have a reasonable handle on > the topic. I'm not sure if my enthusiasm is shared by the other > developers though. Either way, this would be a big new feature, True. The code modifications aren't really all that big, though, and since I've proposed it as an "opt-in" feature (this could be changed in the future, of course), it should at least be pretty safe. > and it > will require some discussion from the core developers and the rest of > the community. I was hoping this would help spur the discussion. > However, we're currently on a push to get v1.0 out the door, and in > order to get this release out the door, we're deferring discussions on > feature requests that aren't already well established. Although the feature request might be regarded as well established (since various aspects of it have been requested in the tickets I listed as long as three years ago) I did realize that my patch might be postponed by the push to release 1.0, even if there were a lot of interest in it. While of course I would rather that didn't happen (since it's a feature I use in a patched version of 0.96), I figured it would still worth working on as a post-1.0 feature--although in that case, hopefully the transition from 1.0 to the next version would be shorter than that from 0.96 to 1.0. > I'm not saying you shouldn't work on this - just that you will find it > difficult to get our attention over the next few months. If we want to > get v1.0 out the door, some things have to be sacrificed. If I can determine that there is sufficient interest that there's a decent chance of it being used (always assuming the implementation is found acceptable, of course), I'll definitely work on it. > Yours > Russ Magee %-) Thanks. Mike --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Support for ON DELETE and ON UPDATE in foreign keys
Hi Mike, > If I can determine that there is sufficient interest that there's a > decent chance of it being used (always assuming the implementation is > found acceptable, of course), I'll definitely work on it. +1 This feature would be very nice to have. Thanks! Sander --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Introducing ModelView, a RESTful class-based view of your resources
Salut Clément, Le 19 juin 08 à 16:15, tifosi a écrit : > > Hi David, > > Thank for your code and the repository, I use the django-rest- > interface and > it's good news, that someone continue the job. > > I would like to get nested resources (e.g.: /articles/1/comments/ or > /user/username/jobs/) and the problem is that you have to pass > statically > the queryset. I think I can use a decorator but I don't know how I > can do > this. Do you have a suggestion? I'll think about that this weekend, I have some ideas about the way to handle that in an easy way. > > > (Sorry for my English, I'm French) Nobody is perfect ;) Cheers, David ps : you can join us on #django-fr --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Introducing ModelView, a RESTful class-based view of your resources
Thanks for your quick answser ! I join #django-fr and #django. Are you on these channels ? About the solution, I subclass Collection and Entry. Perhaps we can pass the nested Collection to the master Collection ? But we must also pass the reg exp of nested Collection. Bonne soirée Clément David Larlet wrote: > > > Salut Clément, > > Le 19 juin 08 à 16:15, tifosi a écrit : >> >> Hi David, >> >> Thank for your code and the repository, I use the django-rest- >> interface and >> it's good news, that someone continue the job. >> >> I would like to get nested resources (e.g.: /articles/1/comments/ or >> /user/username/jobs/) and the problem is that you have to pass >> statically >> the queryset. I think I can use a decorator but I don't know how I >> can do >> this. Do you have a suggestion? > > I'll think about that this weekend, I have some ideas about the way to > handle that in an easy way. >> >> >> (Sorry for my English, I'm French) > > Nobody is perfect ;) > > Cheers, > David > > ps : you can join us on #django-fr > > > > > > > -- View this message in context: http://www.nabble.com/Introducing-ModelView%2C-a-RESTful-class-based-view-of-your-resources-tp17718460p18035051.html Sent from the django-developers mailing list archive at Nabble.com. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSOC: More backends for djangosearch
On Thu, Jun 19, 2008 at 10:47:36PM +0100, Ben Firshman wrote: > Not that I just want to copy other projects, but it'd would be nice to > bring together all the best features of all the Django search > solutions that already exist. It would be ideal if the developers of > all these projects (django-sphinx in particular seems the most mature) > would be willing to assist with djangosearch. With their expertise on > their search backends, we can make it contrib worthy. As a developer on a Django/Solr project [0], I'm keen on the possibilities for integrating search engines with Django. A couple of questions: 1. You mention integration with Lucene. Do you mean to do this via Solr or PyLucene? 2. What's the relationship between django-search [1] and djangosearch [2]? Seems like some collaboration/combination could happen there. [0] http://code.google.com/p/fac-back-opac/ [1] http://code.google.com/p/django-search/ [2] http://code.google.com/p/djangosearch/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Database weirdness in test harness
Hi all,
I'm trying to pin down what I think is a bug in Model.delete(), but
I'm encountering bizarre behaviour with my tests that I can't
reproduce in normal circumstances. In particular, it is as if
foreign key constraint checking has been turned off.
The attached patch adds tests that can be run with:
./tests/runtests.py --settings=your.settings.module delete
Currently the tests pass, but they shouldn't -- the DELETE statement
should produce an IntegrityError or OperationalError (or, if 'ON
DELETE CASCADE' was set then the subsequent queries should return
nothing). If I try similar things outside the test harness, I get
the exceptions I expect.
I'm testing this using a Postgres database, I've also tested with
sqlite and get the same thing, I haven't tested with MySQL.
Can anyone else confirm what I'm seeing? It is very bizarre. Does
anyone know if the test harness does something unusual with
constraints?
Cheers,
Luke
--
"I am going to let you move around more, just to break up the
mahogany." (True Quotes From Induhviduals, Scott Adams)
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Index: tests/modeltests/delete/__init__.py
===
--- tests/modeltests/delete/__init__.py (revision 0)
+++ tests/modeltests/delete/__init__.py (revision 0)
@@ -0,0 +1 @@
+
Property changes on: tests/modeltests/delete/__init__.py
___
Name: svn:eol-style
+ native
Index: tests/modeltests/delete/models.py
===
--- tests/modeltests/delete/models.py (revision 0)
+++ tests/modeltests/delete/models.py (revision 0)
@@ -0,0 +1,59 @@
+# coding: utf-8
+"""
+Tests for some corner cases with deleting.
+"""
+
+from django.db import models
+
+class DefaultRepr(object):
+def __repr__(self):
+return u"<%s: %s>" % (self.__class__.__name__, self.__dict__)
+
+class Member(DefaultRepr, models.Model):
+name = models.CharField(max_length=100)
+
+class Poll(DefaultRepr, models.Model):
+created_by = models.ForeignKey(Member, related_name="polls_created")
+
+class PollOption(DefaultRepr, models.Model):
+text = models.CharField(max_length=100)
+poll = models.ForeignKey(Poll, related_name="poll_options")
+
+class VoteInfo(DefaultRepr, models.Model):
+poll_option = models.ForeignKey(PollOption, related_name="votes")
+member = models.ForeignKey(Member, related_name="poll_votes")
+
+
+__test__ = {'API_TESTS': """
+>>> from django.db.models import sql
+>>> from django.db import connection
+>>> m = Member(name="joe")
+>>> m.save()
+>>> p = Poll(created_by=m)
+>>> p.save()
+>>> po = PollOption(text="An option", poll=p)
+>>> po.save()
+>>> vi = VoteInfo(poll_option=po, member=m)
+>>> vi.save()
+
+# This should fail:
+>>> c = connection.cursor()
+>>> c.execute("DELETE FROM delete_member;", [])
+
+>>> # Alternative can be done like this:
+>>> #q = sql.DeleteQuery(Member, connection)
+>>> #q.delete_batch([m.id])
+
+# Why doesn't the above fail? Are constraints turned off or something?
+# From the below, it would seem they are:
+
+>>> Poll.objects.all()
+[]
+>>> Member.objects.all()
+[]
+
+# The thing I really want to test:
+# m.delete()
+
+"""
+}
Property changes on: tests/modeltests/delete/models.py
___
Name: svn:eol-style
+ native
Re: Database weirdness in test harness
Django builds a list of all the objects that are foreign keyed to the
one you are deleting and deletes those first, so it bypasses any ON
DELETE clauses. I assume this is what you're seeing.
I'm preparing to propose a patch that will add ON DELETE and ON UPDATE
support to Django (so that you can specify whether to CASCADE, RESTRICT,
etc., in the ForeignKey definition directly in the Django model model),
but it probably won't be accepted before the Django 1.0 release (and
maybe not after--who knows). In the meantime, you can disable this
behavior by finding the django.db.models.base._collect_sub_objects
function and modifying it as follows:
> def _collect_sub_objects(self, seen_objs):
> """
> Recursively populates seen_objs with all objects related to this object.
> When done, seen_objs will be in the format:
> {model_class: {pk_val: obj, pk_val: obj, ...},
> model_class: {pk_val: obj, pk_val: obj, ...}, ...}
> """
> pk_val = self._get_pk_val()
> if pk_val in seen_objs.setdefault(self.__class__, {}):
> return
> seen_objs.setdefault(self.__class__, {})[pk_val] = self
>
> return #INSERT THIS RETURN TO DISABLE DJANGO'S PSEUDO "ON CASCADE DELETE"
>
> for related in self._meta.get_all_related_objects():
> rel_opts_name = related.get_accessor_name()
> if isinstance(related.field.rel, OneToOneRel):
> try:
> sub_obj = getattr(self, rel_opts_name)
> except ObjectDoesNotExist:
> pass
> else:
> sub_obj._collect_sub_objects(seen_objs)
> else:
> for sub_obj in getattr(self, rel_opts_name).all():
> sub_obj._collect_sub_objects(seen_objs)
Mike
Luke Plant wrote:
> Hi all,
>
> I'm trying to pin down what I think is a bug in Model.delete(), but
> I'm encountering bizarre behaviour with my tests that I can't
> reproduce in normal circumstances. In particular, it is as if
> foreign key constraint checking has been turned off.
>
> The attached patch adds tests that can be run with:
>
> ./tests/runtests.py --settings=your.settings.module delete
>
> Currently the tests pass, but they shouldn't -- the DELETE statement
> should produce an IntegrityError or OperationalError (or, if 'ON
> DELETE CASCADE' was set then the subsequent queries should return
> nothing). If I try similar things outside the test harness, I get
> the exceptions I expect.
>
> I'm testing this using a Postgres database, I've also tested with
> sqlite and get the same thing, I haven't tested with MySQL.
>
> Can anyone else confirm what I'm seeing? It is very bizarre. Does
> anyone know if the test harness does something unusual with
> constraints?
>
> Cheers,
>
> Luke
>
>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Database weirdness in test harness
On Friday 20 June 2008 23:40:43 Michael Glassford wrote: > Django builds a list of all the objects that are foreign keyed to > the one you are deleting and deletes those first, so it bypasses > any ON DELETE clauses. I assume this is what you're seeing. Yes, this is the area I'm testing, I'm aware of how Django currently does it (and I'm investigating a bug in Django's cascading delete). What I'm talking about is the way that foreign key constraints apparently are ignored inside the test harness -- did you try the tests in the patch? Luke -- "I asked mom if I was a gifted child. She said they certainly wouldn't have paid for me." (Calvin and Hobbes) 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Database weirdness in test harness
On Sat, Jun 21, 2008 at 6:30 AM, Luke Plant <[EMAIL PROTECTED]> wrote: > Hi all, Hi Luke - Great to see you back and committing again! :-) > Currently the tests pass, but they shouldn't -- the DELETE statement > should produce an IntegrityError or OperationalError (or, if 'ON > DELETE CASCADE' was set then the subsequent queries should return > nothing). If I try similar things outside the test harness, I get > the exceptions I expect. > > I'm testing this using a Postgres database, I've also tested with > sqlite and get the same thing, I haven't tested with MySQL. I get the same result. The SQLite failure isn't surprising - SQLite doesn't have row referential integrity. Neither does MySQL (using MyISAM tables), so the test passes under MySQL. (well... SQLite and MySQL actually both fail the test, but only because of the expected output - the deletion itself works fine). However, I can explain the behaviour. You're missing two important lines: >>> from django.db import transaction >>> transaction.commit() When you commit the transaction, you get the integrity error you expect. This isn't specific to the test system either - it's an artefact of getting a manual cursor. You get the same result when you use a python shell (from ./manage.py shell). Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
