Re: Request of Ajax Status
On 5/10/06, Bryan <[EMAIL PROTECTED]> wrote: > > I understand that this is not a priority for Django, but I would like > to know if anyone is working on Ajax support in Django. I read through > the proposals and was wondering if I could do anything to help with one > of the layers (preferably with the view, because I'm sure that needs > the most work). > > I am close to finishing up my Dojo code and need to do this anyways to > get Ajax (really Ajaj -- j for JSON) working with Django. If I am > going to do this, I might as well contribute somehow. > > So, please, let me know if any work is currently in the works so that I > don't have to try to reinvent anything. > > p.s. sorry if this is a duplicate post, but google is requesting that I > resubmit. (i've never used this system before). > > Bryan > I've written an AJAX ( or AJAJ :) replacement for the fields in forms. It is based on dojo's combobox widget with a little tweaking to work in django forms and skinning to look nice with the default django look and feel. I've just written up a wiki page on it now at http://code.djangoproject.com/wiki/AJAXWidgetComboBox regards matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: multi-auth branch... time to merge?
On 5/31/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > Has anyone tested out the multi-auth branch yet? I haven't heard > anything, so either people aren't using it, or it's working well and > the docs are good enough. Personally, I've been using it with both > external SQL and LDAP backends for over a month now. No issues, but my > apps are internal and don't get much traffic. > > Thanks, > Joseph > I've been on leave for 3 weeks but I really want to try it out now I'm back at work. I port my ldap auth stuff to it and let you know how it goes. matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ticket #1891 review? distinct=True no longer works in limit_choices_to
Hi, This ticket #1891 [1] has been outstanding for quite a while. I'm in the process of rolling out a large application that would really benefit from this being fixed. Is anyone able to look at it? Malcolm, did you ever get around to proving your idea in your last comment in the ticket? [1] http://code.djangoproject.org/ticket/1891 thanks matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django and LDAP support
On 10/08/06, Scott Paul Robertson <[EMAIL PROTECTED]> wrote: > On Wed, Aug 09, 2006 at 08:00:31PM -0700, Gary Wilson wrote: > > > Scathing comments are encouraged. > > > > line 68 of patch: > > if not username and password is not Null: # we need a user/pass > > Should be None > > d'oh! Figures I'd mistype something like that. > > > And how about moving the ldap.initialize() call after the above check > > so that we don't make an unneeded connection to the ldap server. > > You know it was on my list, and I missed it when I was going through my > cleanup today. Thanks. > > > Also, in the ldap setup I deal with, you must bind to the server using > > a service account before attempting a bind with the user-supplied > > credentials. The process goes something like > > > > 1. Retrieve the username and password from the user. > > 2. Bind to the directory using DN and password of service account. > > 3. Issue a search query to determine the user's DN based on their > > username. > > 4. Attempt to bind to the directory using the user's DN retrieved in > > step 3 and the password supplied by the user in step 1.. > > 5. A successful bind means that the user has been authenticated. An > > unsuccessful bind means that the credentials provided are invalid. > > > > This also seems to be the method used/needed in the second resource > > link you listed in your first post. It would be great if this method > > could be supported. It would require a few more options like > > LDAP_SERVICE_BIND_DN > > LDAP_SERVICE_BIND_PASSWORD > > and then an additional check in authenticate() (after the call to > > initialize() and before the bind with the user's DN and password) to > > see if first a bind should be attempted with the service account DN and > > password. > > > > I'll start on this tomorrow. Out of curiosity how common is this sort of > setup? I've only seen a handful of LDAP implementations, and this is new > to me. > My LDAP setup does a similar thing. In fact my old (pre-magic removal) LDAP auth code did it but I hadn't gotten around to rewriting it. Thanks for saving me the effort! > Thanks for the comments, > Scott > > -- > Scott Paul Robertson > http://spr.mahonri5.net > GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Bump #708: search on IPAddressField with postgres backend is broken
Hi, I hit this bug 10 months ago when I first started using Django and it still hasn't been addressed. As per my comments in the ticket I feel that the use of the inet type in the postgresql backend is a special case that is the root of the issue. Using a char(15) like every other backend would fix the issue and remove this special case. This will definitely cause backwards compatibility issues though. opinions? regards matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
schema-evolution: status?
I had some to make some changes to some models today that would result in schema changes so I decided to give the schema-evolution branch a go. I didn't get far as the script I use to load sample data into my applications failed [1] and trying to manually add data via my public CRUD views failed because 'User' object has no attribute 'is_authenticated'. So it seems the branch is quite far behind the trunk. Any chance of merging the latest trunk changes in the schema-evolution branch? [1] http://paste.e-scribe.com/1384/ regards matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: schema-evolution: status?
Derek, On 31/08/06, Derek Anderson <[EMAIL PROTECTED]> wrote: > > hey matt, > > would you be willing to send me a copy of your app, your original > schema, and whatever load script failed? > > derek Unfortunately I can't send you a copy of the app. However looking at your branch it seems it may benefit from a merge from a more recent revision of the trunk or atleast with the 0.95 release (See my message below re: the User.is_authenticated() missing from your branch) Alternatively I'm on #django if we can manage to hook up there. matthew > > > Matthew Flanagan wrote: > > I had some to make some changes to some models today that would result > > in schema changes so I decided to give the schema-evolution branch a > > go. > > > > I didn't get far as the script I use to load sample data into my > > applications failed [1] and trying to manually add data via my public > > CRUD views failed because 'User' object has no attribute > > 'is_authenticated'. So it seems the branch is quite far behind the > > trunk. > > > > Any chance of merging the latest trunk changes in the schema-evolution > > branch? > > > > > > [1] http://paste.e-scribe.com/1384/ > > > > regards > > > > matthew > > > > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: schema-evolution: status?
On 01/09/06, Derek Anderson <[EMAIL PROTECTED]> wrote: > > i merged with head before i checked it in. unless i really frelled up > w/ svn, it should only be ~2 weeks behind. I think you may have "frelled up". Your branch was created on 07/11/06 and from the revision log [1] it does appear that you've merged any changes from the trunk in since then. In fact if I do a merge from trunk at the last revision (r3644) before your checked in your schema-evolution code it shows a bunch of changes: $ cd ~/src $ svn co http://code.djangoproject.com/svn/django/branches/schema-evolution $ cd schema-evolution $ svn merge --dry-run -r3332:3644 http://code.djangoproject.com/svn/django/trunk Udjango/dispatch/license.txt Udjango/dispatch/saferef.py Udjango/dispatch/errors.py Udjango/dispatch/robust.py Udjango/dispatch/robustapply.py Udjango/dispatch/dispatcher.py Udjango/http/__init__.py Udjango/contrib/auth/backends.py Udjango/contrib/auth/views.py Udjango/contrib/auth/__init__.py Udjango/contrib/auth/models.py Udjango/contrib/auth/decorators.py Udjango/contrib/auth/forms.py Udjango/contrib/syndication/feeds.py Udjango/contrib/comments/models.py Udjango/contrib/comments/templatetags/comments.py Udjango/contrib/comments/feeds.py Udjango/contrib/comments/views/karma.py Udjango/contrib/comments/views/comments.py Udjango/contrib/comments/templates/comments/form.html Udjango/contrib/flatpages/views.py Udjango/contrib/flatpages/README.TXT Udjango/contrib/sessions/middleware.py Udjango/contrib/sessions/models.py Udjango/contrib/admin/media/css/layout.css Udjango/contrib/admin/media/css/global.css Udjango/contrib/admin/media/css/rtl.css Udjango/contrib/admin/media/css/changelists.css Udjango/contrib/admin/media/css/forms.css Udjango/contrib/admin/media/js/admin/RelatedObjectLookups.js Udjango/contrib/admin/media/js/admin/CollapsedFieldsets.js Udjango/contrib/admin/media/js/admin/DateTimeShortcuts.js Udjango/contrib/admin/utils.py Udjango/contrib/admin/filterspecs.py Udjango/contrib/admin/templatetags/admin_modify.py Udjango/contrib/admin/templatetags/admin_list.py Udjango/contrib/admin/urls.py Udjango/contrib/admin/views/template.py Adjango/contrib/admin/views/auth.py Udjango/contrib/admin/views/main.py ...etc etc [1] http://code.djangoproject.com/log/django/branches/schema-evolution > > could you send just your models? (+ load script, original schema) > Sorry, as I stated before I can't shared the code as it is for an internal project for my employer. I'll just say that I haven't actually try to "evolve" any schema yet, I'm just trying to get my project up and running on your branch. regards matthew > > Matthew Flanagan wrote: > > Derek, > > > > On 31/08/06, Derek Anderson <[EMAIL PROTECTED]> wrote: > >> hey matt, > >> > >> would you be willing to send me a copy of your app, your original > >> schema, and whatever load script failed? > >> > >> derek > > > > Unfortunately I can't send you a copy of the app. However looking at > > your branch it seems it may benefit from a merge from a more recent > > revision of the trunk or atleast with the 0.95 release (See my message > > below re: the User.is_authenticated() missing from your branch) > > > > Alternatively I'm on #django if we can manage to hook up there. > > > > matthew > > > >> > >> Matthew Flanagan wrote: > >>> I had some to make some changes to some models today that would result > >>> in schema changes so I decided to give the schema-evolution branch a > >>> go. > >>> > >>> I didn't get far as the script I use to load sample data into my > >>> applications failed [1] and trying to manually add data via my public > >>> CRUD views failed because 'User' object has no attribute > >>> 'is_authenticated'. So it seems the branch is quite far behind the > >>> trunk. > >>> > >>> Any chance of merging the latest trunk changes in the schema-evolution > >>> branch? > >>> > >>> > >>> [1] http://paste.e-scribe.com/1384/ > >>> > >>> regards > >>> > >>> matthew > >>> > >> > > > > > > > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: name of test database
On 04/09/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > On 9/4/06, Ned Batchelder <[EMAIL PROTECTED]> wrote: > > > > > > Partly on this topic: I would very much like to use sqlite in-memory > databases for testing, even though I use MySQL for deployment. The speed > difference is 10x. One way to do this is to have a TEST_DATABASE_ENGINE > setting, and add logic to create_test_db(). > > > > Thoughts? > > > > If there were a TEST_DATABASE_ENGINE setting, it would imply that there were > analogs of all the other DATABASE_ settings, too. I can't say I'm crazy > about this idea. 'Deploy under MySQL, but test under PostgreSQL' isn't a > particularly compelling use case for me. IMHO, testing for one database but > deploying onto another sort of defeats the purpose of testing. > > However, when you are developing unit tests, having a fast turnaround on > test execution is certainly desirable; using SQLite in-memory is certainly > one way to get this fast turnaround. > > Rather than having TEST_DATABASE_ENGINE (which implies that ANY database > engine could be used), I would be inclined to have a TEST_IN_MEMORY setting, > which forces all tests to be run in SQLite, using an in memory database. > > Furthermore, I would be inclined to make this a command line option, rather > than a permanent setting. IMHO, tests should always be executed against the > _actual_ database that will be used during deployment. Although there > _shouldn't_ be any differences between databases, there occasionally will be > - either due to kinks in Django, or because you are deploying custom SQL. > Providing a command line option would provide a workaround to get fast > development turnarounds without compromising the default (read - preferable) > testing conditions. > > Opinions? > > Yours, > Russ Magee %-) > > I don't see the need for Django specific TEST_* settings when it is simple enough to do this in myapp/testsettings.py: from myapp.settings import * DATABASE_ENGINE='sqlite3' DATABASE_NAME=':memory:' and use ./manage.py --settings=myapp.testsettings. matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
On 14/09/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
>
> On 9/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >
> > Hence, with this new API, the above view code would be written like this:
> >
> > form = ContactForm()
> > if request.method == 'POST' and form.is_valid(**request.POST):
> > send_email_and_redirect()
> > return render_to_response('email_form.html', {'form':
> > form.bind(**request.POST)})
> >
>
> "send_email_and_redirect()"
> I want that function. Surely, this is a basic example, but it hides some of
> the other issues that need to be hammered out. How do you access the
> data once it's validated? How do validation aware models interact
> with this BoundForm? Does the user have to set up a try, except block
> when they save an object or does the form know something about the
> model that allows it to validate it with the validation aware model?
> Finally, how does one set the default data?
>
> > The template would look like this:
> >
> > ...
>
> Personally I think it should be like this:
>
> {% render-form form %}
>
>
> That should give you almost exactly what the Admin does. If you want
> more control, then you should be able to, but for the most simple
> case, this should be possible.
>
> > 1. form.sendername.errors.as_url rather than
> > form.sendername.html_error_list. This gives us some flexibility to add
> > other error shortcut-display types, like JavaScript or something.
>
> Don't we have template tags for this sort of stuff? I favor a
> "to_html" for just about everything in the common case, including
> error lists. Otherwise, a filter or template tag should be used, or
> the object's class could be subclassed do define other functionality.
> (Come to think of it: the template rendering should check for a
> "to_html" or ''__html__'' function before it tries str() when it comes
> across "{{ object }}")
>
> > Let's change this to be similar to model classes, like so:
> >
> > class ContactForm(Form):
> > sendername = TextField()
> > senderemail = EmailField()
> > subject = TextField(maxlength=20, blank=True)
> > message = TextField()
> >
>
> +1
>
> I also think some extra default kwargs should be available:
>attributes = the rendererd tag>
>label =
>
> For instance, using the given example:
>message = TextField(label='Your message',
> attributes={'class':'vRichTextField'})
>
+1 on this for me. I'd love to be able to do:
author = SelectField(attributes={'dojoType': 'Select'})
> > One big change, other than the syntax, is that 'is_required' is
> > dropped, in favor of 'blank', to match our model syntax. Also, as in
> > models, blank=False will be default. Currently in manipulators,
> > is_required=False is default.
>
> This is backwards to me. "is_required" is much more descriptive;
> "blank" seems to say "this field is blank". I agree that it should
> match up with the model, but I posit that the model syntax should
> change. New users constantly ask about this in the chat-room; they
> don't see a difference between "blank" and "null" in the model syntax.
> I prefer "required", which is easier to understand, and is part of
> the common web parlance: "required fields are marked in red". I don't
> care whether it's default or not, although I would suggest polling
> many real-world cases to find the most common option.
>
> >
> > Another big change is that each of the Fields in this ContactForm
> > would be responsible primarily for *validation* rather than specifying
> > the HTML form field. This decouples the concept of validation from the
> > HTML form type.
> >
>
> I don't understand this, and I think might hold the key to a greater
> understanding of your plans, could you explain how validation would
> work exactly? Also, I agree with limodou that there should be a
> general "validate" function that allows the writer of the Form to
> provide some custom validation on the form as a whole. Likewise there
> should be a "convert" function that does the same but for conversion
> from HTML-POST data to Python data.
>
> > Another thing to note: In the current Manipulator framework, sometimes
> > it is convenient to be able to construct self.fields dynamically. We
> > should provide a way to do that with the new syntax.
>
> +1
>
> > So that's the proposal -- thoughts/criticisms? I'd like to get this
> > out there as soon as possible, because we (or, rather, I) have dawdled
> > for quite some time!
>
> Some things occur to me:
>
> The whole BoundForm and Form thing is really crufty. When does the
> Form NOT have data associated with it? And when would you really want
> to have it validate data but not "bind" that data?
>
> There needs to be a fundemental change in the model syntax as well,
> which I'm sure you don't want to hear, but it's true. Half
> (hyperbolishly) of the stuff that is in the model syntax is really
> there to define the Form. You have this sort of siamease twin, but
> I'm not sure if
Re: schema-evolution: status?
Derek,
I have manually merged the trunk into my local working copy of the
schema-evolution branch and started playing with it. I wanted to
question the SQL "sqlevolve" is outputting. I have this model in an
application called "asset":
class Interface(models.Model):
name = models.CharField(maxlength=64, core=True, db_index=True,
help_text='The name of the interface as given by the asset.')
interfacetype = models.ForeignKey(InterfaceType)
ipaddress = models.ForeignKey(IPAddress, verbose_name='IP Address',
raw_id_admin=True)
# allow for EUI-48 and EUI-64 addresses
mac_address = models.CharField(maxlength=24, blank=True,
help_text='The EUI-48 or EUI-64 physical address of the interface.')
domain = models.CharField(maxlength=255, blank=True,
help_text='The DNS domain this host resides in.')
asset = models.ForeignKey(Asset, edit_inline=models.TABULAR,
num_in_admin=10, num_extra_on_change=5)
objects = InterfaceManager()
def _get_meta(self):
return self._meta
meta = property(_get_meta)
def __str__(self):
return "%s:%s" % (self.asset, self.name)
def get_absolute_url(self):
return self.asset.get_absolute_url()
class Meta:
ordering = ['name']
unique_together = (('asset', 'name'),)
class Admin:
pass
and the schema from "./manage.py sql asset":
CREATE TABLE "asset_interface" (
"id" serial NOT NULL PRIMARY KEY,
"name" varchar(64) NOT NULL,
"interfacetype_id" integer NOT NULL,
"ipaddress_id" integer NOT NULL REFERENCES "ip_ipaddress" ("id"),
"mac_address" varchar(24) NOT NULL,
"domain" varchar(255) NOT NULL,
"asset_id" integer NOT NULL REFERENCES "asset_asset" ("id"),
UNIQUE ("asset_id", "name")
);
when I run "./manage.py sqlevolve asset" with absolutely no changes to
my models it outputs:
BEGIN;
ALTER TABLE "asset_interface" ADD COLUMN "name_tmp" varchar(64);
UPDATE "asset_interface" SET "name_tmp" = "name";
ALTER TABLE "asset_interface" DROP COLUMN "name";
ALTER TABLE "asset_interface" RENAME COLUMN "name_tmp" TO "name";
ALTER TABLE "asset_interface" ALTER COLUMN "name" SET NOT NULL;
COMMIT;
Any ideas why it is doing this?
regards
matthew
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: schema-evolution: status?
postgresql
On 14/09/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> which backend are you using?
>
> Matthew Flanagan wrote:
> > Derek,
> >
> > I have manually merged the trunk into my local working copy of the
> > schema-evolution branch and started playing with it. I wanted to
> > question the SQL "sqlevolve" is outputting. I have this model in an
> > application called "asset":
> >
> > class Interface(models.Model):
> > name = models.CharField(maxlength=64, core=True, db_index=True,
> > help_text='The name of the interface as given by the asset.')
> > interfacetype = models.ForeignKey(InterfaceType)
> > ipaddress = models.ForeignKey(IPAddress, verbose_name='IP Address',
> > raw_id_admin=True)
> > # allow for EUI-48 and EUI-64 addresses
> > mac_address = models.CharField(maxlength=24, blank=True,
> > help_text='The EUI-48 or EUI-64 physical address of the interface.')
> > domain = models.CharField(maxlength=255, blank=True,
> > help_text='The DNS domain this host resides in.')
> > asset = models.ForeignKey(Asset, edit_inline=models.TABULAR,
> > num_in_admin=10, num_extra_on_change=5)
> > objects = InterfaceManager()
> >
> > def _get_meta(self):
> > return self._meta
> > meta = property(_get_meta)
> >
> > def __str__(self):
> > return "%s:%s" % (self.asset, self.name)
> >
> > def get_absolute_url(self):
> > return self.asset.get_absolute_url()
> >
> > class Meta:
> > ordering = ['name']
> > unique_together = (('asset', 'name'),)
> >
> > class Admin:
> > pass
> >
> > and the schema from "./manage.py sql asset":
> >
> > CREATE TABLE "asset_interface" (
> > "id" serial NOT NULL PRIMARY KEY,
> > "name" varchar(64) NOT NULL,
> > "interfacetype_id" integer NOT NULL,
> > "ipaddress_id" integer NOT NULL REFERENCES "ip_ipaddress" ("id"),
> > "mac_address" varchar(24) NOT NULL,
> > "domain" varchar(255) NOT NULL,
> > "asset_id" integer NOT NULL REFERENCES "asset_asset" ("id"),
> > UNIQUE ("asset_id", "name")
> > );
> >
> >
> > when I run "./manage.py sqlevolve asset" with absolutely no changes to
> > my models it outputs:
> >
> > BEGIN;
> > ALTER TABLE "asset_interface" ADD COLUMN "name_tmp" varchar(64);
> > UPDATE "asset_interface" SET "name_tmp" = "name";
> > ALTER TABLE "asset_interface" DROP COLUMN "name";
> > ALTER TABLE "asset_interface" RENAME COLUMN "name_tmp" TO "name";
> > ALTER TABLE "asset_interface" ALTER COLUMN "name" SET NOT NULL;
> > COMMIT;
> >
> >
> > Any ideas why it is doing this?
> >
> > regards
> >
> > matthew
> >
> > >
> >
>
>
> >
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
pybots.org
Hi, I've noticed a couple of tickets with patches coming in for python 2.5. As I mentioned in this thread [1], it might be useful for the django project to get a buildbot builder or two going on a few of the slaves at http://pybots.org. These can be used to test django against python 2.5 and 2.6. Python 2.5 comes with pysqlite built in, though you still have to build the actual sqlite3 binaries too, so this would make it quite easy to run the tests against that. A more advanced buildbot builder might run the tests against all the database backends that django supports. The advantage of this is even better user visibility and confidence that the django trunk is stable. To do this properly really requires someone with admin access to code.djangoproject.com so they can set up the post-commit hook to notify the buildbot slave to run the tests. I am using buildbot internally at my company to test our OS & application baremetal installation system, which has dozens of unique application builds and is all driven from a django frontend. [1] http://groups.google.com/group/django-users/browse_thread/thread/7a7b8f5a1b63012b opinions? takers? regards matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: pybots.org
Bad form to reply to myself but... On 20/09/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > Hi, > > I've noticed a couple of tickets with patches coming in for python > 2.5. As I mentioned in this thread [1], it might be useful for the > django project to get a buildbot builder or two going on a few of the > slaves at http://pybots.org. > > These can be used to test django against python 2.5 and 2.6. Python > 2.5 comes with pysqlite built in, though you still have to build the > actual sqlite3 binaries too, so this would make it quite easy to run > the tests against that. A more advanced buildbot builder might run the > tests against all the database backends that django supports. > > The advantage of this is even better user visibility and confidence > that the django trunk is stable. > > To do this properly really requires someone with admin access to > code.djangoproject.com so they can set up the post-commit hook to > notify the buildbot slave to run the tests. Nothing needs to be done by the django admins as the test builds are only triggered by commits to the python repo not the django one. So perhaps I might find some time to get this going. > > I am using buildbot internally at my company to test our OS & > application baremetal installation system, which has dozens of unique > application builds and is all driven from a django frontend. > > [1] > http://groups.google.com/group/django-users/browse_thread/thread/7a7b8f5a1b63012b > > opinions? takers? > > regards > > matthew > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: attribute__isnull=True vs attribute__exact=None (Ticket 2737)
Hi Russ, Is http://code.djangoproject.com/ticket/2400 is related to this as well? On 12/10/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > Hi All, > > I've hit upon an interesting bug, which is related to ticket 2737 > (currently listed as a feature request, but I think there is an > argument that the requested feature is required as a bug fix). > Consider the following model: > > class Poll(models.Model): > name = models.CharField(maxlength=100) > > class Choice(models.Model): > name = models.CharField(maxlength=100) > poll = models.ForeignKey(Choice) > > Create some dummy data, then run the following sequence of commands: > > > p = Poll() > > p.choice_set.all() > > i.e., a related manager on unsaved object. This returns _all_ Choice > objects in the database. It turns out that this is because the related > manager is based upon a 'relatedname__pk=%d' % pk_value' query. > However: > > > Choice.objects.filter(poll__pk=None) > > returns all Choice objects in the database, because any query where > value=None is outright ignored - no error, no warning. As a side note, > this also means that: > > > Choice.objects.filter(foo__pk=None) > > _also_ returns all choice objects in the database, with no error, even > though foo isn't a valid attribute name. > > To me, all three of these behaviours are counterintuitive. To me, the > choice_set of an unsaved object should be empty, pk=None (and, by > extension, id__exact=None) corresponds nicely to id__isnull=True, and > an invalid attribute should always raise an error. > > Ticket 2737 requests a feature where __exact=None would be interpreted > as __isnull=True. This would fix all three problems I have described. > The proposed patch isn't correct, but I feel the idea is valid. > > As a quick test, I removed line 710 of query.py (the line that exludes > value=None queries), and none of the unit tests failed, so it doesn't > appear that ignoring value=None queries is explicitly required. > Obviously, it is desirable for other query types, like __range=None, > but there hasn't been an explicit test-driven requirement that > value=None queries are ignored. However, this could be an indication > of deficiencies in the regression suite. > > Also, fixing this problem is problematic because it encroaches upon > Malcolm's refactor of the QuerySet code. > > Comments? Have I missed an obvious problem? Have I missed a ticket in > the database that describes this problem already? Malcolm, can you > comment on the potential impact a short term fix for this problem > would have on your refactor work? > > 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 -~--~~~~--~~--~--~---
Re: Call for testing: New setup.py
Hi Adrian, On 17/10/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Hi all, > > I've refactored Django's setup.py so that it uses the plain Python > distutils installation method rather than ez_setup/setuptools. This > means it no longer requires an Internet connection to install Django. > Hooray! > > But I have only tested this on Linux, so I'd appreciate it if folks > could test out the command "python setup.py install" on various > different platforms. Just grab the SVN version of Django and try > installing it using "python setup.py install". In the buildbot slave I'm setting up for pybots.org I get a problem with the old setuptools version of django-admin.py not being replaced by the real one. My setup has a temporary python2.5 build in /tmp/python-buildbot/local/bin/python with django trunk r3905 (pre-setuptools removal) installed in /tmp/python-buildbot/local/lib/python2.5/site-packages. If I do a '/tmp/python-buildbot/local/bin/python setup.py install' with the latest trunk it doesn't replace the /tmp/python-buildbot/local/bin/django-admin.py script or remove the old django egg. If I then go and remove the old egg from site-packages django-admin.py breaks. If I do a completely clean install without a previous setuptools version of django present then it works fine. This is on a Solaris 10 system with python 2.5. > > For the record, we previously discussed this on django-developers here: > > http://groups.google.com/group/django-developers/browse_thread/thread/af002765821b5e57/27a927caaee9ad78 > > The "straw that broke the camel's back," in this case, happened this > weekend when I was doing a Django tutorial in Boston and encountered > two people who'd had problems installing Django due to a setuptools > problem that was out of our control. (Namely, it was due to the fact > that Python 2.5's version of setuptools required a certain version of > ez_setup, or vice versa, or some other peculiar problem like that, > which was out of our control.) > > There was something about seeing this problems in real life, with > face-to-face conversations with real Django users, that finally put me > over the edge. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.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 -~--~~~~--~~--~--~---
django build slave
Hi, I've now got a Solaris 10 sparc buildbot slave up and running at: http://www.python.org/dev/buildbot/community/all/ It is running the django trunk tests against both python 2.5 and python trunk using a sqlite3 memory database. Are any of the core developers interested in receiving test failure emails? regards matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: Ticket spam
Hi Adrian, On 25/10/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 10/24/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > It appears that some little inbred turd has decided that the ticket > > submission page is a great place to drop their little nuggets of > > spammy goodness, and as far as I can make out Askimet isn't blocking > > them. > > > > Is there anything we can do to remove these twits from the gene pool - > > or at the very least, stop them from urinating in our pond? > > I've been going through and mercilessly deleting all spam tickets and > comments, using a script I wrote that reverts changes. (I submitted it > to Trac's Trac here: http://trac.edgewall.org/ticket/3641 .) Ideally > we'd have a way to do that in a distributed way for trusted users -- > any ideas? > > Also, I've been mulling over the idea of requiring an account signup > in order to post tickets and comments. Would that be worth the pain? > In one project I know of that uses trac they just have a single login for users to create tickets and submit patches rather than requiring every user to register. This eliminated 99% of their trac spam. They just documented the login/password in their 'contributing' docs. This saves someone having to manage trac users. > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.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 -~--~~~~--~~--~--~---
Re: schema-evolution: status?
Vic,
On 26/10/06, Victor Ng <[EMAIL PROTECTED]> wrote:
>
> Any luck with schema evolution lately?
>
I haven't done anything further with it since my last email in this
thread. Nor have I had any response from the developer regarding the
issue I previously highlighted.
Other django users would be more likely to test this branch out if it
were up to date with the latest trunk.
regards
matthew
> I'm starting to look at seeing if i can merge this back to trunk as
> well, but wanted to know if you've made any progress.
>
> I'm using the postgresql_psycopg2 backend.
>
> vic
>
> On 9/14/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
> >
> > postgresql
> >
> > On 14/09/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
> > >
> > > which backend are you using?
> > >
> > > Matthew Flanagan wrote:
> > > > Derek,
> > > >
> > > > I have manually merged the trunk into my local working copy of the
> > > > schema-evolution branch and started playing with it. I wanted to
> > > > question the SQL "sqlevolve" is outputting. I have this model in an
> > > > application called "asset":
> > > >
> > > > class Interface(models.Model):
> > > > name = models.CharField(maxlength=64, core=True, db_index=True,
> > > > help_text='The name of the interface as given by the asset.')
> > > > interfacetype = models.ForeignKey(InterfaceType)
> > > > ipaddress = models.ForeignKey(IPAddress, verbose_name='IP Address',
> > > > raw_id_admin=True)
> > > > # allow for EUI-48 and EUI-64 addresses
> > > > mac_address = models.CharField(maxlength=24, blank=True,
> > > > help_text='The EUI-48 or EUI-64 physical address of the
> > > > interface.')
> > > > domain = models.CharField(maxlength=255, blank=True,
> > > > help_text='The DNS domain this host resides in.')
> > > > asset = models.ForeignKey(Asset, edit_inline=models.TABULAR,
> > > > num_in_admin=10, num_extra_on_change=5)
> > > > objects = InterfaceManager()
> > > >
> > > > def _get_meta(self):
> > > > return self._meta
> > > > meta = property(_get_meta)
> > > >
> > > > def __str__(self):
> > > > return "%s:%s" % (self.asset, self.name)
> > > >
> > > > def get_absolute_url(self):
> > > > return self.asset.get_absolute_url()
> > > >
> > > > class Meta:
> > > > ordering = ['name']
> > > > unique_together = (('asset', 'name'),)
> > > >
> > > > class Admin:
> > > > pass
> > > >
> > > > and the schema from "./manage.py sql asset":
> > > >
> > > > CREATE TABLE "asset_interface" (
> > > > "id" serial NOT NULL PRIMARY KEY,
> > > > "name" varchar(64) NOT NULL,
> > > > "interfacetype_id" integer NOT NULL,
> > > > "ipaddress_id" integer NOT NULL REFERENCES "ip_ipaddress" ("id"),
> > > > "mac_address" varchar(24) NOT NULL,
> > > > "domain" varchar(255) NOT NULL,
> > > > "asset_id" integer NOT NULL REFERENCES "asset_asset" ("id"),
> > > > UNIQUE ("asset_id", "name")
> > > > );
> > > >
> > > >
> > > > when I run "./manage.py sqlevolve asset" with absolutely no changes to
> > > > my models it outputs:
> > > >
> > > > BEGIN;
> > > > ALTER TABLE "asset_interface" ADD COLUMN "name_tmp" varchar(64);
> > > > UPDATE "asset_interface" SET "name_tmp" = "name";
> > > > ALTER TABLE "asset_interface" DROP COLUMN "name";
> > > > ALTER TABLE "asset_interface" RENAME COLUMN "name_tmp" TO "name";
> > > > ALTER TABLE "asset_interface" ALTER COLUMN "name" SET NOT NULL;
> > > > COMMIT;
> > > >
> > > >
> > > > Any ideas why it is doing this?
> > > >
> > > > regards
> > > >
> > > > matthew
> > > >
> > > > >
> > > >
> > >
> > >
> > > >
> > >
> >
> > >
> >
>
>
> --
> "Never attribute to malice that which can be adequately explained by
> stupidity." - Hanlon's Razor
>
> >
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Re: schema-evolution: status?
Hi Derek, To do the merge you need to look at the last revision that you merged from trunk or in your case when your branch was created. In this case it is revision 3332. So to merge the latest trunk you need to: cd django_tmp_src svn merge -r 3332:HEAD http://code.djangoproject.com/svn/django/trunk [resolve and conflicts and test your code] svn co -m 'merged latest changes from trunk' To keep up to date with the trunk you just need to run an 'svn log' in your working copy and look at the last revision that you merged from the trunk, rev xyz say, and use that like this: svn merge -r xyz:HEAD http://code.djangoproject.com/svn/django/trunk etc regards matthew On 26/10/06, Derek Anderson <[EMAIL PROTECTED]> wrote: > > "svn merge http://code.djangoproject.com/svn/django/trunk"; gives me the > "svn help merge" message. > > here's what i did: > > $ svn co > http://code.djangoproject.com/svn/django/branches/schema-evolution/ > django_tmp_src > [normal checkout crap] > > $ cd django_tmp_src/ > > $ svn merge http://code.djangoproject.com/svn/django/trunk > [help message] > > > god i miss cvs... > > > > Kenneth Gonsalves wrote: > > > > On 26-Oct-06, at 12:40 PM, Derek Anderson wrote: > > > >> can someone who knows svn better than i help me out as to how i would > >> refresh the branch with the latest from the trunk, and then remerge > >> these changes back into it? > > > > in your working copy root do: > > > > svn merge http://code.djangoproject.com/svn/django/trunk > > > > and then, after resolving conflicts do > > > > svn commit > > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
schema-evolution: postgres introspection bug
Hi,
I've been testing out the schema-evolution branch again and hit the
same issue I was having before where it was trying to evolve a model
that hadn't changed. Here are my minimal test case models for this
issue:
from django.db import models
class FooType(models.Model):
name = models.CharField(maxlength=64, unique=True)
class Foo(models.Model):
name = models.CharField(maxlength=64)
foo_type = models.ForeignKey(FooType)
running './manage.py sqlevolve myapp' outputs:
BEGIN;
ALTER TABLE "myapp_foo" ADD COLUMN "name_tmp" varchar(64);
UPDATE "myapp_foo" SET "name_tmp" = "name";
ALTER TABLE "myapp_foo" DROP COLUMN "name";
ALTER TABLE "myapp_foo" RENAME COLUMN "name_tmp" TO "name";
ALTER TABLE "myapp_foo" ALTER COLUMN "name" SET NOT NULL;
COMMIT;
Note that if I rename the FooType model to BarType and do a fresh
install of my application again then run './manage.py sqlevolve myapp'
it outputs the expected:
BEGIN;
COMMIT;
Same goes if I rename the Foo.name field to something else.
This led me to think that some code somewhere is not matching on the
full table name. After a bit of digging I ended up at the
get_known_column_flags() function in
django/db/backends/postgresql/introspection.py on line 100 it reads:
cursor.execute("select pg_constraint.conname, pg_constraint.contype,
pg_attribute.attname from pg_constraint, pg_attribute where
pg_constraint.conrelid=pg_attribute.attrelid and
pg_attribute.attnum=any(pg_constraint.conkey) and
pg_constraint.conname ~ '^%s'" % table_name )
Changing '^%s' to '^%s_' fixes it but I'm not sure if this is the
right way to do it.
Is it?
regards
matthew
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: schema-evolution: postgres introspection bug
On 01/11/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've been testing out the schema-evolution branch again and hit the
> same issue I was having before where it was trying to evolve a model
> that hadn't changed. Here are my minimal test case models for this
> issue:
>
> from django.db import models
>
> class FooType(models.Model):
> name = models.CharField(maxlength=64, unique=True)
>
> class Foo(models.Model):
> name = models.CharField(maxlength=64)
> foo_type = models.ForeignKey(FooType)
>
> running './manage.py sqlevolve myapp' outputs:
>
> BEGIN;
> ALTER TABLE "myapp_foo" ADD COLUMN "name_tmp" varchar(64);
> UPDATE "myapp_foo" SET "name_tmp" = "name";
> ALTER TABLE "myapp_foo" DROP COLUMN "name";
> ALTER TABLE "myapp_foo" RENAME COLUMN "name_tmp" TO "name";
> ALTER TABLE "myapp_foo" ALTER COLUMN "name" SET NOT NULL;
> COMMIT;
>
> Note that if I rename the FooType model to BarType and do a fresh
> install of my application again then run './manage.py sqlevolve myapp'
> it outputs the expected:
>
> BEGIN;
> COMMIT;
>
> Same goes if I rename the Foo.name field to something else.
>
> This led me to think that some code somewhere is not matching on the
> full table name. After a bit of digging I ended up at the
> get_known_column_flags() function in
> django/db/backends/postgresql/introspection.py on line 100 it reads:
>
> cursor.execute("select pg_constraint.conname, pg_constraint.contype,
> pg_attribute.attname from pg_constraint, pg_attribute where
> pg_constraint.conrelid=pg_attribute.attrelid and
> pg_attribute.attnum=any(pg_constraint.conkey) and
> pg_constraint.conname ~ '^%s'" % table_name )
>
> Changing '^%s' to '^%s_' fixes it but I'm not sure if this is the
> right way to do it.
>
> Is it?
Nope it isn't. If i rename the FooType model to Foo_Type I get the
same issue as before. ie. sqlevolve
Back to my original models, FooType and Foo. The output from the above
select statement is:
# select pg_constraint.conname, pg_constraint.contype,
pg_attribute.attname from pg_constraint, pg_attribute where
pg_constraint.conrelid=pg_attribute.attrelid and
pg_attribute.attnum=any(pg_constraint.conkey) and
pg_constraint.conname ~ '^myapp_foo';
conname| contype | attname
++-
myapp_foo_pkey | p | id
myapp_footype_pkey | p | id
myapp_footype_name_key | u | name
(3 rows)
This is where I reach the boundaries of my postgres knowledge.
Any help would be appreciated.
thanks
>
> regards
>
> matthew
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
changeset 3960 broke something with DateTimeField's
Hi,
I'm using postgres DB with the following model:
class Contact(models.Model):
"""
Contact details for a person, role, organization or org unit.
"""
name = models.CharField(maxlength=128, db_index=True)
organisation = models.CharField(maxlength=128, blank=True)
department = models.CharField(maxlength=128, blank=True)
phone1 = models.CharField(maxlength=16, blank=True)
phone2 = models.CharField(maxlength=16, blank=True)
phone3 = models.CharField(maxlength=16, blank=True)
email = models.EmailField(blank=True)
web_site = models.URLField(blank=True)
# from old Addressee model
address1 = models.CharField(maxlength=64, blank=True, core=True)
address2 = models.CharField(maxlength=64, blank=True)
address3 = models.CharField(maxlength=64, blank=True)
address4 = models.CharField(maxlength=64, blank=True)
city = models.CharField(maxlength=64, blank=True)
state = models.CharField(maxlength=32, blank=True)
post_code = models.CharField(maxlength=16, blank=True)
country = models.CharField(maxlength=64, blank=True)
# Audit fields
created = models.DateTimeField('created', default=models.LazyDate(),
blank=True)
created_by = models.ForeignKey(User, verbose_name='created by',
related_name='directory_contact_created_by', blank=True)
changed = models.DateTimeField('last changed', auto_now=True)
changed_by = models.ForeignKey(User, verbose_name='last changed by',
related_name='directory_contact_changed_by', blank=True)
When I try and create a Contact and save it I get the following error.
This worked fine up until r3960 was checked in a few days ago.
>>> from nong.directory.models import Contact
>>>Contact(name='foo').save()
Traceback (most recent call last):
File "", line 1, in ?
File "/xxx/django/django/db/models/base.py", line 204, in save
','.join(placeholders)), db_values)
File "/xxx/django/django/db/backends/util.py", line 12, in execute
return self.cursor.execute(sql, params)
psycopg.ProgrammingError: ERROR: column "created" is of type
timestamp with time zone but expression is of type integer
HINT: You will need to rewrite or cast the expression.
INSERT INTO "directory_contact"
("name","organisation","department","phone1","phone2","phone3","email","web_site","address1","address2","address3","address4","city","state","post_code","country","created","created_by_id","changed","changed_by_id")
VALUES
('foo','','','','','','','','','','','','','','','',2006-11-06,NULL,'2006-11-06
17:44:37.445033',NULL)
regards
matthew
--~--~-~--~~~---~--~~
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: Branch Merges?
On 07/11/06, Gábor Farkas <[EMAIL PROTECTED]> wrote: > > Jay Parlar wrote: > > On 11/6/06, David Blewett <[EMAIL PROTECTED]> wrote: > >> I would like to suggest that the branches that are felt to be complete > >> sans testing be merged into a single branch. I am anxiously awaiting > >> several different branch merges to core but do not have time to check > >> each individual one out to test them. Maybe it's time to begin a larger > >> effort, similar to magic-removal, at merging all these branches? > > > > This is a constant complaint we're seeing now. The problem is, not > > enough people are actually jumping in and testing out the branches. > > The core devs tell people all the time that it's generally safe to run > > Django off the trunk, but if a bunch of untested branches are merged > > in, well, welcome to disaster time. > > > (what follows will be a little critical. please don't get it wrong. i > simply am stating what i think is wrong, and what should be done so that > we can move on, and finish/merge these branches) > > i think the problem is also the documentation (well, the lack of it). > > for example, i was trying to do some branch-testing (actually what i > want is the birth of the unicode-branch, but currently the best way to > achieve it seems to merge the other branches into the trunk :), > > so i arrived at: > > http://code.djangoproject.com/wiki/ActiveBranches > > the status of the various branches: > > for the following 4 branches, the activeBranches page says that they > need end-user testing: > > - fullHistory > - http://code.djangoproject.com/wiki/FullHistory says "Status: Almost > there", and below it's shown that some parts are not done yet > > - rowLevelPermissions > - the http://code.djangoproject.com/wiki/RowLevelPermissionsDeveloper > shows some unit-tests that still do not pass > > - schemaEvolution > - the wiki-pages only talk about (at least 2 different) proposals. > does > that mean that one of the proposals has been implemented? which one? > I don't think any of those proposals reflect what is actually implemented. I've used the schema-evolution branch and have had some issues which are yet to be resolved or even responded to by the developer. > - search-api > - i could not find any documentation about it > > > the rest: > > - multipleDBsupport > - the wikipage says that the author wants to apply some changes from > the oracle-changes, and only then can/should the testing begin > > - genericAuthorization > - under active development > > > so, in short, the only testable branches seems to be fullHistory and > rowLevelPermissions, and even there it's not clear if they are now > considered done, or still in progress. > > > > so, i think those wikipages linked from > http://code.djangoproject.com/wiki/ActiveBranches should be first > updated, and should contain info about the following: > > - if they are finished (ready for testing) or not > - documentation about how it works. > > because otherwise it's quite hard to test. > > i don't know if we should send mails directly to the authors, or they > are reading django-devel... > > > p.s: as i said, i deeply respect the work of the developers on those > branches. all i wrote was with the goal that we can make the life of the > testers easier => get more testing for the branches => merge the > branches into the trunk > > gabor > > > > --~--~-~--~~~---~--~~ 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: #2333 Pt 3 - Test system fixture data
Hi Russell, I've been using Hugo/Georg's stuff.testing [1] framework for quite a while and some of the things I like about it are: a. I can have fixtures located anywhere in my python path and load them. I have project wide fixtures that I use for testing some of my apps without having to duplicate those fixtures in the app's own test directory. b. The fixtures are Python classes and are instantiated and made available in the TestCase test methods. Also, how is hooking up related objects handled by your fixtures? stuff.testing does it by defining pre_save/post_save methods on the fixture which seem far more powerful than simple serialized objects. A fixture and test case from my project: class TestIPAddress4(Fixture): model_name = IPAddress class DATA: address = '192.168.1.1' description = 'IPv4 Test Fixture Network' def pre_save(self, obj, testcase): obj.ipnetwork_id = testcase.TestIPNetwork4.id obj.customer_id = testcase.TestContact.id obj.created_by_id = testcase.TestIPUser.id obj.changed_by_id = testcase.TestIPUser.id class IPTests(ModelTestCase): _fixtures = ( 'nong.test.fixtures.groups', 'nong.test.fixtures.users', 'nong.directory.test.fixtures.directory', 'nong.ip.test.fixtures.ipv4', 'nong.ip.test.fixtures.ipv6', ) # # IPv4 Tests # def testIPAddressLoad4(self): obj = IPAddress.objects.get(address__exact=self.TestIPAddress4.address) self.assertEqual(obj.address, self.TestIPAddress4.address) self.assertEqual(obj.description, self.TestIPAddress4.description) self.assertEqual(obj.ipnetwork.address, self.TestIPNetwork4.address) self.assertEqual(obj.customer.name, self.TestContact.name) regards matthew [1] https://simon.bofh.ms/cgi-bin/trac-django-projects.cgi/wiki/DjangoTesting On 18/12/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: Hi all, Time for the long promised phase 3 of the Django testing framework - fixtures - to make an appearance. I've attached the changes as a single patch to ticket #2333 (http://code.djangoproject.com/tickets/2333 ) The idea here is to exploit the serialization framework to provide a mechanism for describing the contents of a database during a test. Manage.py has a few new options to allow for the insertion and deletion of test data, as well as a mechanism for dumping the current state of a database as a fixture. For the most part, this is fairly straightforward stuff. Inserting data is easy; however, deleting data is much harder. The simple solution (delete database and recreate) is painfully slow; faster mechanisms are not database independent. I now have an implementation that works pretty well for SQLite, MySQL, and post v8.1 versions of Postgres. It is now at the point where it needs some feedback from others, as well as some input from people with more experience than I on Oracle, MSSQL, and early versions of Postgres. Documentation is also required; I will work on this once the design has been accepted. A full walkthrough of the patch is attached to the ticket; Comments and feedback welcome. 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 -~--~~~~--~~--~--~---
Re: Re: #2333 Pt 3 - Test system fixture data
On 20/12/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
On 12/20/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
>
> Hi Russell,
>
> I've been using Hugo/Georg's stuff.testing [1] framework for quite a
> while and some of the things I like about it are:
>
> a. I can have fixtures located anywhere in my python path and load
> them. I have project wide fixtures that I use for testing some of my
> apps without having to duplicate those fixtures in the app's own test
> directory.
This is what settings.FIXTURES_DIR is for. If you have a source of
useful fixture data that you want multiple applications/projects to
use, put the fixture somewhere accessible and reference the directory
in your settings file.
thanks I missed that.
> b. The fixtures are Python classes and are instantiated and made
> available in the TestCase test methods.
The only thing that would make my life easier is if the fixtures
became attributes of the test case, maybe adding a 'name' field like
so:
{
'pk': '15',
'name': 'Author1',
'fields': {
'name': 'John Smith'
}
}
so that in the test case I could do:
class AuthorCase(TestCase):
fixtures = { 'json': ['fixture1']}
def testSomething(self):
# test something with self.Author1
In Hugo's framework self.Author1 is a dummy object that mirrors to the
real one in the DB with the same attributes set including the id. It
saves quite a bit of boilerplate per test where you would normally
have to go fetch the fixture(s) from the DB and then test something
with them.
>
> Also, how is hooking up related objects handled by your fixtures?
By PK value. For example, a JSON snippet:
{
"pk": "15",
"model": "testproject.author",
"fields": {
"name": "John Smith"
}
},
...
{
"pk": "32",
"model": "testproject.article",
"fields": {
"name": "Fixtures are cool",
"authors": [15, 16],
}
},
Article has an m2m relation on Author; the article JSON instance
references the authors as a list of PK values. All the fixtures are
installed as a single transaction, so as long as there are no dangling
PK references, there should be no problems with circular references,
forward references, etc.
> stuff.testing does it by defining pre_save/post_save methods on the
> fixture which seem far more powerful than simple serialized objects.
This is an interesting approach, but not sure if I'm convinced; Here
are two immediate concerns:
- I take it the pre and post targets exist to get around circular and
pre references? While I can see that this is necessary for a python
class to be able to parse and compile, I don't think it's very elegant
for humans to define. The serialization approach means you can put all
the data regarding Article instance 3 in one place; the class approach
means that the article definition is spread over multiple methods in
the fixture class.
- Using the serialization format allows for a simple 'dumpdb' command,
so you can build your fixtures by using your application, then dump
the contents of the database as a fixture. I don't see that an
analogous approach would be possible (or easy) using a programattic
approach.
That said, one of the initial design considerations for the testing
framework was to provide a good set of default features, but to allow
for easy integration with any other testing framework. If you feel
there is something we can do to make integrating Hugo's fixture
approach with the proposed approach, let me know.
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
-~--~~~~--~~--~--~---
Re: Re: django build slave
On 27/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: On 10/16/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > I've now got a Solaris 10 sparc buildbot slave up and running at: > > http://www.python.org/dev/buildbot/community/all/ > > It is running the django trunk tests against both python 2.5 and > python trunk using a sqlite3 memory database. > > Are any of the core developers interested in receiving test failure emails? It only took me two and a half months to respond to this message, but I would definitely be interested in receiving test-failure e-mails. This looks like a very cool system. Adrian Hi Adrian, They aren't sending out failure emails at the moment. You can check both the trunk and 2.5 maintenance branch build statuses at: http://www.python.org/dev/buildbot/community/all/?show=sparc%20Solaris%2010%20trunk&show=sparc%20Solaris%2010%202.5 and there is an rss feed of _all_ failed builds at: http://www.python.org/dev/buildbot/community/all/rss I keep an eye on the RSS feed and can say there haven't been any django checkins that have broken anything and not many python ones either. Buildbot is extremely cool and very flexible. My test environment uses django and buildbot to test config changes, vendor patches etc to our solaris server bare metal installations. All handsfree except for adding the test host(s) into my django app initially. regards matthew --~--~-~--~~~---~--~~ 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: Re: optional arg. 'description' for widget?
On 31/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: On 12/30/06, Alex Koval <[EMAIL PROTECTED]> wrote: > I found that pretty often I need a "description" being passed to field to > display. I already subclassed > a few widgets to get 'description' argument, and display it where needed. > For example here is > modified TextInput widget: > http://dpaste.com/4207/ > > But I feel that the copy/paste I do with code here is wrong. Its much easier > to have this optionally > available inside of django.newforms by default, so if description is passed, > it will be printed. > Yes, 90% of fields do not need description, but sometimes it is needed. Hi Alex, I'd rather avoid feature creep with the newforms library, and I'd consider a "description" to be part of the presentation of a form rather than part of the content of a form. So I don't think we'll add a "description" option for the time being. Of course, there's nothing stopping you from implementing it in your own Widget subclasses, as you've already done. BTW, future questions/proposals like this should go to the django-developers mailing list -- that's where we talk about changes and improvements to Django itself. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com Hi Adrian, Django model fields already have the help_text parameter that is displayed in the admin app and it not easily available to template designers without writing a custom template tag to extract it. I think it would be very useful if the newforms fields had the ability to display the help_text without having to resort to writing a custom tag. regards matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
django pybot filtered rss feed
Hi, I've just updated the RSS feed code to allow you to filter which buildbot builders you want in the feed. To only see the django build failures you can now point your favorite RSS reader at: http://www.python.org/dev/buildbot/community/all/rss?show=sparc%20Solaris%2010%20trunk&show=sparc%20Solaris%2010%202.5 regards matthew --~--~-~--~~~---~--~~ 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: specifying newforms-admin options
On 22/01/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/20/07, Honza Král <[EMAIL PROTECTED]> wrote:
> > why not create a function to do that for you..
> > urls.py is after all a python module, so you could just introduce a function
> >
> > urlpatterns = admin_urls_for_model(
> > MyModel,
> > field_list=[ 'field' ],
> > exclude_actions=[ admin.EDIT ],
> > perms_required={
> > admin.EDIT : 'can_change_MyModel',
> > admin.LIST : 'something_else'
> > }
> > )
>
> I must not have explained this correctly. In the newforms-admin
> branch, all of those options are specified in a class, ModelAdmin. The
> goal here is to figure out how those classes interact with the
> URLconf. There's no need to pass dictionaries around -- all of that
> configuration is in the class.
>
> Something like this is what I had in mind:
>
> """
> from myapp.models import PollAdmin, ChoiceAdmin
>
> urlpatterns = patterns('',
> (r'^admin/', include('django.contrib.admin.urls'), {'models':
> (PollAdmin, ChoiceAdmin)})
> )
> """
>
> The problem here is that each time you add an admin interface to a
> model, you have to remember to add it to your URLconf. Maybe there can
> be a helper function that looks for all Admin classes, as long as you
> save them in a file called admin.py within the app, but that's kind of
> magic.
I'm -1 on adding it to URLconf and would rather see it in settings.py.
Perhaps like:
ADMIN_FIND_ADMIN_CLASSES = True
ADMIN_MODELS = (
'myproj.myapp.admin.PollAdmin',
'someotherproj.someapp.admin.FooAdmin',
)
Where ADMIN_FIND_ADMIN_CLASSES (or whatever we want to call it)
permits autodiscovery of the ModelAdmin classes in the app/admin.py
files. The ADMIN_MODELS settings are explicit ModelAdmins that would
override anything autodiscovered or mbe the only ModelAdmins if
ADMIN_FIND_ADMIN_CLASSES = False.
No Magic there (I think). This would allow developers to have multiple
ModelAdmins for a model and switch between them depending on the
application's deployment requirements.
regards
matthew
ps. if the ModelAdmin class moves out of the inner class is it going
to gain a 'model' attribute?
pps. I'm +1 on the inner Admin class explicitly subclassing ModelAdmin
as opposed to the current magic.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.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: Critical ticket: can cause data loss
On 30/01/07, James Bennett <[EMAIL PROTECTED]> wrote: > > On 1/29/07, Ned Batchelder <[EMAIL PROTECTED]> wrote: > > I don't know that you need to make a release for this fix, but I think you > > should alert people to it. There is a mailing list for announcing releases > > and security issues, right? You should send a message to that list > > announcing the patch. > > I will once I've backported it. The question in my mind is just > whether we need 0.95.2 from this. > I'm +1 on this too. I believe backports and point releases should be made for the following types of bugs: - security - availability e.g. crashing bugs - data integrity e.g. anything that causes data corruption, deletion etc. They cover off what most software vendors consider critical issues. Maybe the triage team could add keywords to that effect to tickets? regards matthew --~--~-~--~~~---~--~~ 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: Django Builbot (was: dbsync for mysql lacks...)
On 30/01/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote: > > Hi, > inline > > On 1/30/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > [..] > > I'm now dreaming of a test service that would automatically run the > > testsuite for a given patch (or multiple patches) with all supported > > database backends ... > > Also thought about that, getting up a buildbot for testing the SVN is > not hard (it's already done on pybots), running the testsuite for a > given patch has a big danger: One could upload a malicious patch just > to f**k the buildbot. Some way would be needed to tell the buildbot > that a patch is to be tested, then it only has to download the patch > from a ticket and start a Build jobs. > > If the core's around here would like to get up a buildbot that runs > the testsuite on the various python versions, and various backends it > can be done! (at least on debian.. :P). And if some security measure > is provided patches on TRAC could also be tested without trouble maybe > a textfield on the ticket telling which patches to check (as some > tickets have lots of patches) to be set by a triage member. > > I could setup the buildbot for testing if it seems to make sense (most > of the work is already done on pybots, only playing with all the > possible combinations is needed). Hi, I run the django pybot. It wouldn't be difficult to add other backends to the tests and is something I've been considering for a while. As for python versions, pybot only tests 2.5 and trunk . Testing against 2.3 and 2.4 would have to be done on another buildbot. I'm fairly busy for the next 2 weeks but I can look at it after that and hopefully add postgresql and mysql backends on top sqlite that is being tested already. regards matthew > > > Michael > Marc > > > > --~--~-~--~~~---~--~~ 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: Django Builbot (was: dbsync for mysql lacks...)
On 31/01/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote: > > On 1/30/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Marc Fargas Esteve: > > That sounds interesting. (Did I mention that it should run python > > versions 2.3, 2.4 and 2.5? ;-) > > As Matthew said this could be done with separate buildbots or slaves > running different jobs. > > > I wouldn't mind doing this on my own computer if it's so easy ;-) > It depends on how Matthew's buildbot works, normally if you have svn > and the required dependencies it just requires a few files and the > buildbot package, the hard work is at the master which, at the most > part, has already been done by Matthew (get the source, set a project, > test it...) > I don't control the pybots master just the slave that does the django builds. The master is responsible for telling the slaves what to build. For pybots it triggers a build whenever any of the python developers commit changes to either the python 2.5 maintenance branch or 2.6 trunk. So only those python versions are available to test against on pybots. Take a look at my build slave test scripts at: http://pybots.googlecode.com/svn/trunk/slave/flanagan-sparc/ and the pybot master config at: http://pybots.googlecode.com/svn/trunk/master/community.cfg Adding more backends would just be a matter of creating a Django-mysql.sh, Django-postgresql.sh, etc scripts to run each backend test as distinct stages. > Then you can make your computer be a new "slave" that received build > jobs from the "master", then the master decides when your slave has to > do things. > > > Perhaps you can pre-build such a thing ready to download for > > everybody who is interested? It's probably easier than building a > > shared buildbot with proper authentication etc. Don't make any > > complicated patch-auto-selection, let the user prepare the source, > > and the buildbot runs the testsuite with all backends and the python > > versions. > > For that to be done the user would need all the different python > versions and backends (with the required database servers) to run it. > A user can already run the tests with one python version and database > or more if he/she has them. But it's not an easy thing to package, > that's why buildbot was written! > > > This could be used to test the trunk with each checkin (or daily), > > or to test all the patches in stage "Ready for checkin". And I'd > > love to have this for triage. > > Buildbot was written for that, the svn repository can tell the > buildbot when a new checking has been done and start a new bunch of > jobs against it. Having this in place the part of taking patches from > trac is not so hard, the problem is to identify which is the correct > patch to test. > > > Michael > Marc > > > > --~--~-~--~~~---~--~~ 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: Django Builbot (was: dbsync for mysql lacks...)
On 31/01/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote: > > Hi Matthew > > On 1/30/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > > I run the django pybot. It wouldn't be difficult to add other backends > > to the tests and is something I've been considering for a while. As > > for python versions, pybot only tests 2.5 and trunk > > . Testing against 2.3 and 2.4 would have to be done on another buildbot. > > At least on debian is not hard to have python 2.3, 2.4 and 2.5 > available on the same box (simply call /usr/bin/python2.X), also > different versions of postgresql can be run side by side (not for > mysql). Maybe a single BuildSet could be created that creates a bunch > of Builds with the different combinations of python+backend. As far as > a slave has the three versions of python and the different backends it > could run the tests. (note that for postgresql there are two > backends!), Anyway there's always virtualization if you need true > isolation and/or different mysql server versions. > > Sure you have far more knowledge of buildbot than me, so any comments > are really appreciated! > The Django buildbot slave is currently running inside a Solaris 10 zone so it is virtualized...kind of. Let me clarify that testing python 2.3 and 2.4 would require a separate buildbot master than pybots unless you can talk the pybots maintainer into running 2.3 and 2.4 tests as well. Why don't you join the pybots mailing list and ask? > > I'm fairly busy for the next 2 weeks but I can look at it after that > > and hopefully add postgresql and mysql backends on top sqlite that is > > being tested already. > > That would be nice, then the only thing left would be the different > versions of python. For which, as you say, those would need to run on > a different buildbot (buildd.djangoproject.com ?) > > Cheers, > Marc. > > PS: I can host a slave and/or the master for the different > python/backends buildbot if you wish. > > > > --~--~-~--~~~---~--~~ 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: Django Builbot (was: dbsync for mysql lacks...)
On 1/31/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote: > > Hi, > inline > > On 1/31/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > > The Django buildbot slave is currently running inside a Solaris 10 > > zone so it is virtualized...kind of. > > > > Let me clarify that testing python 2.3 and 2.4 would require a > > separate buildbot master than pybots unless you can talk the pybots > > maintainer into running 2.3 and 2.4 tests as well. Why don't you join > > the pybots mailing list and ask? > > As far as I know pybots sets new build jobs when changes occur in the > python code base, so If we want to launch build jobs on new commits on > django/trunk we'd need to setup a separate master anyway, wouldn't we? > Having 2.3 and 2.4 there would make it possible to test django/trunk > when commit occur there but not when commit occur on django's SVN. And > I think that the original comment of this thread from Michael was to > keep django's trunk tested on every commit and trying to test patches > from TRAC before they get commited. > > In this scenario, am I wrong or we do need a separate master? Yes you do need another master. > > Cheers, > Marc > -- matthew http://wadofstuff.blogspot.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: Google Summer of Code 2007
On 2/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I be evil about proposals... > > 1. finish this http://code.djangoproject.com/wiki/TextIndexingAbstractionLayer > and get i merged to trunk > 2. finish http://code.djangoproject.com/wiki/FullHistory and get it > merged to trunk ;) > Add to that 3. Finish Schema evolution and merge to trunk 4. Finish Row level permissions and merge to trunk -- matthew http://wadofstuff.blogspot.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: Google Summer of Code 2007
On 2/27/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 2/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > On Feb 26, 3:15 pm, "Matthew Flanagan" <[EMAIL PROTECTED]> wrote: > > > Add to that > > > > > > 3. Finish Schema evolution and merge to trunk > > > 4. Finish Row level permissions and merge to trunk > > > > Actually, I think that the row level permissions will mostly be > > handled by the newforms-admin branch. > > I might have missed something in the discussions somewhere, but I > don't think this is true. The newforms-admin is all about getting the > admin views into newforms, and breaking the admin views out of model > definitions. One of the side effects is that admin permissions will be > a little more customizable - but this won't have any effect outside of > admin. This is one of the issues I have with newforms-admin. Don't both the generic-auth and RLP branches cover what is being done here? I don't see the point of adding something like this that can only be used in the Django admin. Django would be far more attractive to developers if this was a general set of features. > > Row-level permissions is all about setting modify/delete permissions > on a per-instance basis - e.g., preventing users from modifying or > deleting any blog entries that they didn't create. This general set of > features will be available anywhere, not limited to admin. > > For the record, I'd really like to see row-level permissions rolled into > Django. > > Yours, > Russ Magee %-) > > > > -- matthew http://wadofstuff.blogspot.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: Google Summer of Code 2007
On 2/27/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 2/27/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > > > > On 2/27/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > > > I might have missed something in the discussions somewhere, but I > > > don't think this is true. The newforms-admin is all about getting the > > > admin views into newforms, and breaking the admin views out of model > > > definitions. One of the side effects is that admin permissions will be > > > a little more customizable - but this won't have any effect outside of > > > admin. > > > > This is one of the issues I have with newforms-admin. Don't both the > > generic-auth and RLP branches cover what is being done here? > > No, they don't. At the moment, the admin interface uses oldforms. The > newforms-admin interface will use newforms. This is a major change > (hence the branch), but it is required because oldforms will be > deprecated in 0.96, and removed before 1.0. This is the major push > behind newforms-admin. > > In the process, we are taking the opportunity to remove the Admin > definition from the model definition (which is a long overdue design > change), and do some housekeeping that makes it easier to customize > the admin view, and deploy multiple admin views. > > Generic auth is all about allowing any other user login/authentication > scheme. Nothing to do with newforms, but the newforms-admin changes > should make it easier to integrate generic-auth with the admin > framework. > > RLP is all about having permissions on a per instance, rather than > per-class basis. Nothing to do with newforms, but the newforms-admin > changes should make it easier to integrate RLP with the admin > framework. > > > I don't > > see the point of adding something like this that can only be used in > > the Django admin. Django would be far more attractive to developers if > > this was a general set of features. > > Something like what? The port to newforms is required if oldforms is > to be deprecated, and this is the major push behind newforms-admin. > Specifically, I was referring to the has_*_permission() stuff in the new ModelAdmin class. Which is new functionality aside from the oldforms to newforms port. > To boot, the admin features _are_ a general set of features. Most of > the newforms-admin port is about getting generic views and edit_inline > working properly with newforms, beacuse the admin app rely upon the > same tools that are available to every application. The only > difference is that the Admin application (and it is a normal > application like any other) is polished to allow some very specific > customization options that are useful in an admin context, and comes > with some pre-canned templates that are all perty. > > Yours, > Russ Magee %-) > > > > -- matthew http://wadofstuff.blogspot.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: Google Summer of Code 2007
On 2/27/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > On 2/26/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > > > > Specifically, I was referring to the has_*_permission() stuff in the > > new ModelAdmin class. Which is new functionality aside from the > > oldforms to newforms port. > > A lot of the generic-auth and RLP code is nasty stuff to try to > integrate with the admin system. The new methods are very much welcome > by me both as someone very familiar with the per-object-permission > branch, and as the author of the generic-auth branch. The design is > much cleaner. > I agree that it is cleaner but it still limited to the admin system with no generic means available to other applications. I seems [1] that interest in doing this is also waning. I for one am very keen to see RLP branch integrated and I tested it months ago to my satisfaction. [1] http://groups.google.com/group/django-developers/browse_thread/thread/f124083c6194dccc/ > Joseph > > > > -- matthew http://wadofstuff.blogspot.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: Buildbot?
On 4/19/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On 4/18/07, Jonathan Daugherty <[EMAIL PROTECTED]> wrote: > > Do you have a resident buildbot? That could be used to run the > > regression tests on (all pythons) x (all databases). It would still > > take time, of course, but it could at least be automated[1][2]. > > I've spent some time in the past trying to get one set up (I've used > both the buildbot and Bitten, a Trac plugin), but I've not been able > to figure out how to get it working with Django's custom test harness. > > Someone more experienced with automated build tools might have more > success than me, though, and if someone is willing to figure out how > it works and let me know (or just send me a VM) I'll happily provide > hosting! > > Any takers? > > Jacob > The script [1] I'm using for the Django pybots [2] is very simple. The only thing I'd like to get going is testing against different backends. Do you have a problem with running it on pybots, except for the fact it isn't testing against python 2.3 or 2.4? [1] http://pybots.googlecode.com/svn/trunk/slave/flanagan-sparc/Django.sh [2] http://www.python.org/dev/buildbot/community/all/?show=sparc%20Solaris%2010%20trunk&show=sparc%20Solaris%2010%202.5 -- matthew http://wadofstuff.blogspot.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 -~--~~~~--~~--~--~---
editable=False and manipulator.save(data) not working together
Hi,
In my model I have the field:
created_by = meta.ForeignKey(
User,
verbose_name='created by',
editable=False,
blank=True,
null=True
)
and the module method below to create a "validated" object:
def _module_create(address, prefix, description, maintainer,
customer, created_by):
from django.utils.datastructures import MultiValueDict
from django.models.ip import ipsupernetworks
data = MultiValueDict({
'address': [address],
'prefix': [prefix],
'description': [description],
'maintainer': [maintainer.id],
'customer': [customer.id],
'created_by': [created_by.id],
'changed_by': [created_by.id],
})
manipulator = ipsupernetworks.AddManipulator()
errors = manipulator.get_validation_errors(data)
if errors:
return None, errors
else:
manipulator.do_html2python(data)
obj = manipulator.save(data)
return obj, errors
But when I call obj.get_created_by() on a newly created object i get
'None'. When I remove "editable=False" from the field definition it
works.
is this how it is meant to behave? I do not want to have this field in
the admin but be still able to set it in the method above. Is there
another way of doing it? I know i can call mymodule.MyModel(...) but
this doesn't validate the arguments as far as I can tell.
regards
matthew
Re: Proposal: Allow custom redirects in the admin system
On 1/12/06, oggie rob <[EMAIL PROTECTED]> wrote:
>
> > Another option would be to have the callable return a (url, message)
> tuple, and let the view handle HttpResponseRedirect and
> request.user.add_message.
>
> I think you should use a dictionary. For example, you could pass in the
> following dictionary:
> {None:'../report1/%s'}
> and then in the default method:
> else:
>request.user.add_message(msg)
>redir = redir_dict.get(None, '../../')
>return HttpResponseRedirect(redir)
>
> etc. for all types of POST in the method.
>
> Anyway, you could pass this into the change_stage method via the admin
> class, or via urls.py (which is how I'm using this technique).
> ('url1/', 'change_list', {'app_label':'myapp', 'module_name':'mymod'}),
> ('url1/\d+/', 'change_stage', {'app_label':'myapp', 'module_name':
> 'mymod', 'redir_dict':{None:'../report1/%s'}}),
> ('url1/add/', 'add_stage',
> {'app_label':'myapp','module_name':'mymod','redir_dict':{None:'../report1/%s'}}),
>
> or you could write a tiny custom view that does the same and looks
> cleaner!
>
> Of course you could throw the same dict into the admin class to achieve
> the same.
>
> The reason I think it is nice to do this without a custom
> "after_change_action" method is that much of the after_change_action
> code would be duplicated on different modules, but the actual url is
> the part that changes. Also much of the time you will just want to
> redir the "Save" action and none of the others.
>
> -rob
>
>
I've been looking at the same thing in the last day and I found the
'post_url' keyword arg to the add_stage() view that allows you to
redirect somewhere after adding a new object but this arg doesn't
exist for the change_stage() view. Would adding a similar argument to
change_stage() solve this?
matthew
Re: Proposal: Allow custom redirects in the admin system
On 1/12/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> On 1/11/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
> >
> > I've been looking at the same thing in the last day and I found the
> > 'post_url' keyword arg to the add_stage() view that allows you to
> > redirect somewhere after adding a new object but this arg doesn't
> > exist for the change_stage() view. Would adding a similar argument to
> > change_stage() solve this?
>
> Kind of, but that wouldn't allow you to specify new save button action
> types, ("save and continue editing", "save and add X", etc.) and you'd
> have to override urls to get the custom redirect. I'd rather avoid
> that if possible.
>
Similar to a "wizard" style interface? This would be handy for complex models.
> Also, I don't believe post_url would allow you to use something like
> the new object id in your url.
Now that would be useful!
>
> Joseph
>
Re: Any other Australian Django heads?
On 1/31/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > > I'm looking to see how many other australians are interested in > Django, and also to get a list of people interested in some casual > django work (if I get any) on the side. > > -- > [EMAIL PROTECTED] -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909 > > If everything seems under control, you're not going fast enough. - > Mario Andretti > Ian, I'm in sydney. I'm may be interested in casual work depending on my other commitments. matthew
Re: proposal: endif, endfor etc assume whatever follows in tag is comment
On 3/16/06, hugo <[EMAIL PROTECTED]> wrote:
>
> >It's not clear to me that inline comments were outright rejected here.
> >Perhaps I missed some other discussion but to my biased eye the
> >general concensus was favourable.
>
> I remember several situations where Adrian and Jacob rejected an inline
> comment syntax (IRC, tickets, group). I found one directly in the
> ticket system:
>
> http://code.djangoproject.com/ticket/648
>
> That's why I said "shot down often enough to stop the discussion". Even
> though it might be neat to vote on something, at least it should be a
> something where the core devs didn't outright dump the idea earlier on.
> Or if it is, at least bring new arguments to the table that address
> their complaints ;-)
>
> I myself am -0 on inline comment syntax. Reason: comments in templates
> just don mix up for me. I don't see much reason in putting _template_
> comments in there, except as blocks - and in those cases there is
> already the {% comment %} syntax. For other cases web designers will
> much more naturally use HTML comments, as that's the syntax they
> already know about.
>
> Actually comments that don't show up in the generated HTML aren't
> really that useful for design, anyways: as templates do generate HTML,
> and that HTML is quite complex, you _want_ your comments to show up in
> the result, so you can use them as landmarks in the source view.
>
> Actually the only reason I see for {% comment %} at all is to disable a
> block of template code - and therefore I would actually prefer it to be
> renamed to {% disable %} :-)
HTML comments are fine if you are using django.template for generating
HTML or if you want your comments to end up in the final output of the
template. If you are using it for non-HTML output then {% comment %}
blocks are the only way.
>
> bye, Georg
>
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Distributed Applications and Database Data
I sure MR has hooks for this. Have a look in django/contrib/sites/management.py at how it uses the new event system to create the example.com Site object. On 4/28/06, Brantley Harris <[EMAIL PROTECTED]> wrote: > > I've started to impliment my proposal for schema implementation and > realized that some database-data might need to be distributed along > with updates in the actual application, but there is no mechanism for > it. For instance, if an application requires some sort of seed-data, > but the requirement it is added in a new version, anyone who updates > won't have that data. > > Is this sort of thing handled in other frameworks? Has there been any > talk about this at all? > > Thanks > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: magic-removal merge status
Are you going to tag the pre-merge revision of the trunk? On 4/30/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 4/28/06, Ken Kennedy <[EMAIL PROTECTED]> wrote: > > WRT migrating my older app, though...ick. Do you expect more db-schema > > changes of this magnitude before 1.0? > > No, I don't expect any more db schema changes of this magnitude. This > branch is intended to be the last set of *big* backwards-incompatible > changes before 1.0. I'm sure we'll have some more > backwards-incompatible changes before then (such as the removal of > automatic manipulators in favor of validation-aware model objects), > but it shouldn't be anything on the scale of magic-removal. The worst > is behind you. :) > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.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 -~--~~~~--~~--~--~---
