Re: Cannot resolve keyword into field
On 4/21/07, Ramashish Baranwal <[EMAIL PROTECTED]> wrote: > > TypeError: Cannot resolve keyword 'book' into field This is a long-standing, well-known bug that apparently no one (including me) knows how to fix. Any time one defines a ManyToMany relationship, then calls all() on that relationship from a script, a "cannot resolve keyword into field" error results. The problem involves some deep voodoo about how and when modules are imported, which is why it occurs only in scripts but not in the admin interface or the manage.py shell. If you google around the django-users archives and bug tickets, you'll see some (imho truly hideous) hacks for working around it by mangling your import statements. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: audit trail support
On 4/20/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > In your descriptions below, you remove the ability for a developer to > use manual primary keys, by the sound of it, since one of your special > fields wants to be a single-column primary key. That's not invisible. Does Django currently allow use of composite primary keys? If so, I wasn't aware. Either way, the only restriction I would want to put on the keying of the tables is that they not use one of the reserved column names (e.g. "record_is_deleted"). I wouldn't go as far as to say "significantly heavier" without a lot of > profiling under operational loads. Using sensible table indexing, > including functional indexes on databases that have them, should make > that query perform reasonably well for many cases (gut feel based on a > bit of experience with large databases). Fair enough. It definitely makes the queries more complex, since they must always include statements to select the current, non-deleted record. But that doesn't mean the performance would be unacceptable. A real drawback of this method that you don't mention is that adding > audit support requires changing the database table. So you can't add it > to standard (shipped with Django) or third-party modules easily. Yes, I would prefer my solution be drop-in compatible with both standard Django and typical third-party modules. Which does argue against modifying the model tables. > 2. The audit table, as described above, is written seperately > > from the working table used for reads. It would be most > > You still have to change the main table for the model, though, right? > Otherwise you won't be able to have more than one tuple of data for each > model (due to constraint violations). This was a problem that existed in > the design of the FullHistory work as well: how to store arbitrary bits > of changed information without having to alter existing tables. No, I will not need to change the main table for the model. But as you point out, the audit table's schema cannot simply be main table + record-keeping columns. Instead, its schema must be: main table with modified contraints + record-keeping columns. If you could find a way that all the audit-related information was in a > separate table, I would be tempted to implement it similar to > ContentTypes -- as a table that is related to the model(s) it governs > (maybe there is a shadow audit table for each real model table, but > that's a bit uncool from a database design perspective). The extra table > join won't really hurt you with today's databases and proper indexing. Keeping a shadow table for each audit table is looking like the best solution to me right now. Granted it does add a little clutter to the table namespace -- but shadow tables will be created only for models that explictly ask for them. Is it worthwhile to make it possible to store the audit shadow tables in a separate db? I suspect you will be able to do most of it as a third-party app without > needing to hack on core. Some monkey patching -- a term I hate because > it suggests it is wrong somehow, but I'll stick with the common phrase > -- of the QuerySet class might be necessary (replacing QuerySet with a > version that understands how to get the "real" row for a model). You > might be able to get away with subclassing QuerySet in a lot of cases, > but I'm not sure that will give you everything. If I am only interested in writing shadow tables to keep history, don't think I would need to touch QuerySet. Instead, just define some pre_save and pre_delete callbacks for the dispatcher. (And maybe post_save and post_delete, to verify that the save/delete had been successful?) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
audit trail support
I need to add real audit trail and change-notification support to an existing Django app and to one that is under development. The best way to do this, it seems to me, is to add audit support to the Django framework itself. My requirements are similar to those named by Paul Childs in his django-users post<http://groups.google.com/group/django-users/browse_thread/thread/f36f4e48f9579fff>last June: - rows, once written, are immutable -- system should be able to operate without UPDATE and DELETE privileges on the audit db - editing a record creates a new row (with higher version and/or date) but does not touch old record - deleting a record creates a new row to be created with the "record_is_deleted" flag set to true - (optional) whenever a new row is written, user must supply a comment explaining the change - (optional) whenever a new row is written, an email is sent to an address specified in the model To clarify, when I say "row" I mean a literal row in the database; and when I say "record" I mean the representation of a Django model. A record will have many rows associated with it in the audit db, if it has been modified many times. Audit trail support would be enabled on a per-model basis, probably by including an AuditTrail inner class. That inner class would then be used to specify audit options. Beyond including this inner class, and an to-be-determined method for attaching comments to changes, audit trail support should be invisible to developers. Both the existing admin log and the FullHistory <http://code.djangoproject.com/wiki/FullHistory>branch are inadequate for my requirements. I will be working on this project as part of my Real Job(tm), so devoting time to it should not be a problem. However, before I begin coding, I want the community's input on a few issues. What is the right way, at DB level, to implement the audit trail? I had two ideas: 1. The table representing a model with AuditTrail enabled will include fields such as "record_id", "row_id", "record_version", "record_is_deleted", and "row_timestamp". Row_id will be the primary key for the table, but will not be meaningful for identifying a given record. Record_id and record_version will be unique together, and together sufficient for locating the current version of a given record. Reading the current record can be accomplished by a query like "SELECT *, max(record_version) FROM table_name WHERE record_is_deleted IS FALSE GROUP BY record_id", or a database view encapsulating the same query. Advantage: The audit table is guaranteed to be in sync with the production data, since they are one and the same Disadvantage: Significantly heavier database load. 2. The audit table, as described above, is written seperately from the working table used for reads. It would be most useful if the audit table could be written to a wholly separate database. The working table is unchanged from today's Django. Advantage: Fairly trivial increase in database load Disadvantage: In the event of an application error, it would be possible for the working table and audit table to get out of sync 3. I am open to better suggestions. Perhaps the core developers can tell me, will it be possible to do this as a contrib plugin? I would, of course, rather do it as a plugin than hack on the Django core. But either way, my ultimate goal is to create a high quality solution that can be included in the main trunk. Lastly, would it have been more appropriate to post this to django-developers? Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: selecting a framework ,
Django is a great framework for building custom web apps -- but I am not sure it is the most sensible solution for your needs. If what you want is standard ERP functionality, delivered over the web, there is no need for you to reinvent the wheel. Quite a few existing open source projects may meet your needs; check out OpenBravo, Compiere, ERP5, webERP, etc. On 4/19/07, gops <[EMAIL PROTECTED]> wrote: > > > Hi , > > I want to develop a ERP for very small business ( two - three use + > customer : normally not more than 10 people using the erp ) , I know a > little bit of php , but i am interested in django as my platform , > > my question is , is there any such system available which i can look > at to get some idea , from where to start... ??? > > Thanks . > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: database table prefix
thanks! the db_table option will probably work. I might have to change the code unless there is a way to set this for a global db_table, such as the auth_user table. On Feb 27, 5:24 pm, "Marc Fargas Esteve" <[EMAIL PROTECTED]> wrote: > Prefixes have been discussed sometimes, you can look at ticket #891 > i.e. Or search this group about that... > > One "hackish" option you could go on is use different SITE_ID's in > your sites, and either make your applications take care of SITE_ID (a > foreignkey to Sites could help) or set the db_table Meta option > something like: > > from django.conf import settings >db_tabe = 'this_app_table_site_%d' % settings.SITE_ID > > but I'd rather make the applications understand SITE_ID and work accordingly. > > Cheers, > Marc > > On 2/28/07, Jason Sidabras <[EMAIL PROTECTED]> wrote: > > > > > Sorry, mis-typed before. But I'm trying to see how this might work for > > my case. > > > My mistake was that I am not trying to create multiple databases. Just > > multiple tables. > > > So app named foo typically creates a table: > > foo_news > > > and I would like it to be: > > site_one_foo_news > > > Jason > > > On Feb 27, 5:03 pm, "Rubic" <[EMAIL PROTECTED]> wrote: > > > You could assign DATABASE_PREFIX as an > > > environment variable, then have settings.py > > > get the value (untested): > > > > # settings.py > > > import os > > > DATABASE_PREFIX = os.environ['DATABASE_PREFIX'] > > > DATABASE_NAME = "site_%s_foo" % DATABASE_PREFIX > > > > Then run manage.py from the command line: > > > > $ DATABASE_PREFIX="one" ./manage.py ... > > > $ DATABASE_PREFIX="two" ./manage.py ... > > > > -- > > > Jeff Bauer > > > Rubicon, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: database table prefix
Sorry, mis-typed before. But I'm trying to see how this might work for my case. My mistake was that I am not trying to create multiple databases. Just multiple tables. So app named foo typically creates a table: foo_news and I would like it to be: site_one_foo_news Jason On Feb 27, 5:03 pm, "Rubic" <[EMAIL PROTECTED]> wrote: > You could assign DATABASE_PREFIX as an > environment variable, then have settings.py > get the value (untested): > > # settings.py > import os > DATABASE_PREFIX = os.environ['DATABASE_PREFIX'] > DATABASE_NAME = "site_%s_foo" % DATABASE_PREFIX > > Then run manage.py from the command line: > > $ DATABASE_PREFIX="one" ./manage.py ... > $ DATABASE_PREFIX="two" ./manage.py ... > > -- > Jeff Bauer > Rubicon, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
database table prefix
Does django currently support a DATABASE_PREFIX option? The question arises because of a problem I am having with sqlite and my hosting provider. And the end of the day I would like to have three website which use some combinations of the same apps. These websites do not share "stories" from the databases. Example: I have a app named foo. foo has three models one, two three. site one has a setting file DATABASE_PREFIX set to site_one. running a ./manage.py --settings=settings_siteone syncdb would give me: creating database site_one_foo doing the same for site two would give me: creating database site_two_foo now both sites have a different database but use the same app. I have looked into site redirect but I don't think that is for me. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: urls parameter - deliver query set
Hi:
DId you ever find a solution to this? I'm having a similar probme but
want to deliver the query set like:
http://www.foo.com/books?a=12345
Jason.
On Feb 3, 6:52 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> i would like to deliver a query set to a view by url.
> I used pickle to serialize the queryset:
>
> books = book.objects.filter(author='wallman')
> books_ser = pickle.dumps(books)
>
> then i used
>
> url = "/books/%s/" %(books_ser)
> a return HttpResponseRedirect(url)
>
> urlpatterns = patterns('frontend.books.views',
> (r'^books/(?P\w+)/$', 'show_books'),
> )
>
> The problem is the white spaces which are replace by %20, so the url
> pattern don't accept this string as one string!
> Is there a way to deliver query set, objects, list, dicts by urls on
> this way?
> Is there a better way to deliver this? (i don't find any think in the
> doc)
>
> nice we,
>
> pex
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Use a simple query string.
Can anyone help with my super simple query string problem I'm simply trying to get www.mysite.com/uptodate?build=123 parsed. The problem is I can't get any URL to match (I keep getting 404 - page not found). My URL: (r'^uptodate(?P\d+)/$)', prog.main.uptodate'), My View: def uptodate(request, build='123'): --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Complex Data Models.
Hi: Specifically, I'm curious how you do it without putting SQL in the view. From what I understand about the methodology of MVC this should not be done. J. On 12/27/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: On 12/27/06, Jason <[EMAIL PROTECTED]> wrote: > What do we do in Django if we want to use complex data models like > JOINs, or a shopping card with invoices and line-items? Do we try and > keep as much in the database as possible using stored procedures or > views? > > What happens to the model when you want to do more than just SELECT x, > y, z FROM A? Hi Jason, You're best off asking a more specific question. There are indeed ways to perform JOINs in Django, and it's certainly possible to implement a shopping cart with invoices and line-items. Provide a more specific question, and we'll show you how to do it. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com > -- .... Jason C. Leach PGP Key: 0x62DDDF75 Keyserver: gpg.mit.edu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Complex Data Models.
What do we do in Django if we want to use complex data models like JOINs, or a shopping card with invoices and line-items? Do we try and keep as much in the database as possible using stored procedures or views? What happens to the model when you want to do more than just SELECT x, y, z FROM A? J. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: ChoiceField and dynamic input?
You're correct, we found the same thing on IRC. However, to get a
ChoiceField to render your choices in the Select widget, you set
field.widget.choices, not field.choices. This is, of course, not documented
and incredibly confusing. I'm filing a ticket on it now. Thanks for making
it clear.
On 12/27/06, Jason Barrett Prado <[EMAIL PROTECTED]> wrote:
You're correct, we found the same thing on IRC. However, to get a
ChoiceField to render your choices in the Select widget, you set
field.widget.choices, not field.choices. This is, of course, not
documented and incredibly confusing. I'm filing a ticket on it now. Thanks
for making it clear.
On 12/27/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
>
> On 12/27/06, Jason Barrett Prado <[EMAIL PROTECTED]> wrote:
> > Is this even possible, or is it not implemented correctly yet? I have
> done
> > every last thing I can think of that makes any sense and the results
> are
> > never what I want.
> >
> > if not request.POST.has_key('submit'):
> > s = get_object_or_404(School, pk=school_name)
> > f = UserRegistrationForm()
> > f.fields ['house'].widget.choices = [('test','test')]
> > return render_to_response(' register.html', {'reg_form':f})
> > f = UserRegistrationForm(data=request.POST)
> > f.fields['house'].widget.choices = [('test','test')]
> > if not f.is_valid():
> > return render_to_response(' register.html', {'reg_form':f})
> >
> > I fill in the form and POST it and it tells me that 'test' is not a
> valid
> > response for house. Why? I can call clean and full_clean on the data
> after
> > changing the choices, but it doesn't help. How should one do this?
>
> I'm not quite sure what you're trying to do here, but my immediate
> answer is: Don't set the choices on the Widget. Set the choices on the
> Field. You're getting the validation error because the *Field* does
> validation, not the Widget, and a Field has to know what its valid
> choices are in order to do validation correctly.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com
>
> > >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: Project and App Layout.
Thanks for the tip. That looks promising. Where do you usually put your index page - as it's a landing page, and a bit of a gateway to may of the apps that comprise your project? Do you create an app for it, or generally stuff it in a flatpages and hang your other apps off it (like a log in, registration, news or shopping section). Thanks, J. On 12/27/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: On 12/27/06, Jason <[EMAIL PROTECTED]> wrote: > So when I start a new project, it has some basic content like an index, > about, contact, and so on. Where does this go in relation to a apps and > projects? Should I create an app in my project of all this standard > stuff? Hey Jason, Sounds like a great candidate for the Flatpages app, which comes with Django. See the docs here: http://www.djangoproject.com/documentation/flatpages/ It's also covered in the Django Book here: http://www.djangobook.com/en/beta/chapter15/#cn93 The gist of it is that it gives you a lightweight framework for storing one-off pages like the about/contact pages. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com > -- .... Jason C. Leach PGP Key: 0x62DDDF75 Keyserver: gpg.mit.edu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Project and App Layout.
Hi: So when I start a new project, it has some basic content like an index, about, contact, and so on. Where does this go in relation to a apps and projects? Should I create an app in my project of all this standard stuff? Later I'll add functionality. This may include a registration section (with underlying code) and a login section (with code) and perhaps a shopping section (with code). I can see those going into in depended apps in my project (and that's where I'll put them). But I'm still not sure where to put the generic 'meat-n-potatoes' of my site. For now I just created a app called 'main' and am putting all my fairly static content in it. Thanks, Jason. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Can't get my URLs right.
Thanks. Probably the one thing I didn't try. J. On 12/27/06, Jorge Gajon <[EMAIL PROTECTED]> wrote: On 12/27/06, Jason <[EMAIL PROTECTED]> wrote: > > So now that I add an about page, as www.foo.com/about what I get is a > bunch of 404 errors because it's looking form my CSS and images in: > /about/css/styles.css (should be /css/styles.css) and images references > in the CSS in about/css/i/abc.png (should be i/abc.png). I don't > really want to keep recurring and linking my file system to make this > work. > Hi Jason, You need to write absolute urls in your html, for example, instead of: You have to: Notice the slash at the beginning of "/css/styles.css". Regards, Jorge > -- .... Jason C. Leach PGP Key: 0x62DDDF75 Keyserver: gpg.mit.edu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Can't get my URLs right.
Hi: So I started a Django project, got my templates to serve, go my index going, gome some static content to serve. My index page works on http://www.foo.com/ So now that I add an about page, as www.foo.com/about what I get is a bunch of 404 errors because it's looking form my CSS and images in: /about/css/styles.css (should be /css/styles.css) and images references in the CSS in about/css/i/abc.png (should be i/abc.png). I don't really want to keep recurring and linking my file system to make this work. So what I want is all my CSS to be retrieved from /css/ and all my images from /i/. Easy as that. So I need to understand why it's going /about/css and stop it. Thanks, Jason. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Displaing Images and Static Paths
Hi: Sorry for the lame question but this not at all obvious for a new user to Django. I can get my templates to display just fine, but I can't get the images in them to appear and I don't want to write a view for all my imags. Bahhh. I keep images in /i/ in the template directories: like i/foo.png. But I get 404 errors because django's dev server can find those without a few. So how do I get my images out? I'd really like to serve them out using the standard . Thanks in advance. J. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
RE: So I made a forum with Django
Are you developing that forum w/ django? regards, Jason == Jason Wydro project engineer w3developing toll free: (800) 615-6493 local: (971) 732-5055 fax: (971) 223-3668 mobile-mail: [EMAIL PROTECTED] email: [EMAIL PROTECTED] web: www.w3developing.com == -Original Message- From: django-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, November 03, 2006 12:38 PM To: Django users Subject: Re: So I made a forum with Django Sure.. send it out. I am using a version of Myghty, at least in testing. http://gretschpages.com/forum/ but I love seeing how other folks do things. There oughta be some sort of django forum group that could take the good work from Zyons, Myghty and this one, merge the best ideas, and build a single killer Django forum. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
One project, multiple apps, all using their own DB
I'm a django newbie (still working on the first app). I'm trying to figure out how to do something, only conceptually at this point. So I have no errors to send. I host a few apps on my home machine. They each use their own DB (on the same server). I'm thinking I should set up a project for the whole server, and then an application for each existing app. But what is the "django way" to change the DB information for each app? I obviously have to change DATABASE_NAME for each app, but what is the least painful way to do this? I've read this post: http://groups.google.com/group/django-users/browse_thread/thread/16d63ef40ffea2d3/8405c641779c50e5%238405c641779c50e5 and this page: http://www.djangoproject.com/documentation/settings/ but light bulb isn't going off above my head. Please help the newb. Thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: syncdb without shell access
Robin Gruyters <[EMAIL PROTECTED]> writes: >> > > My hosting provider doesn't give shell access, so I can't >> > > execute like "syncdb", "startapp", "startproject", etc. >> > > >> > > Is there another way to do this? (e.g. by creating a runsync.py >> > > script?! (or something?)) If you can access the database provided by your hosting provider remotely, then you can use your local copy of your project to run syncdb: just modify your local settings.py to point to your database on your provider, and run syncdb there. -- +---+ | Jason F. McBrayer[EMAIL PROTECTED] | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it.-- Dogen| --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Problems with __str__ methods in my Models
Yes it's me again :)
Anyway I've populating my Models with __str_ methods. I've only had on
hicough.
Here is the model in question:
class Result(models.Model):
ID = models.IntegerField(primary_key=True)
home_runs = models.IntegerField("home team runs", null=True, blank=True)
away_runs = models.IntegerField("visiting team runs", null=True,
blank=True)
game = models.ForeignKey(Game, db_column='game')
ump1 = models.ForeignKey(Ump, related_name='result_ump1',
db_column='ump1')
ump2 = models.ForeignKey(Ump, related_name='result_ump2',
db_column='ump2')
def __str__(self):
return "%s: %i (%i)" % (self.game.datetime.strftime("%Y-%m-%d"),
self.game.away.number, self.away_runs)
class Meta:
db_table = 'result'
class Admin:
pass
When I jump into the shell (python manage.py shell) to try it out...
>>> Result.objects.all()
Traceback (most recent call last):
File "", line 1, in ?
File
"/usr/local/lib/python2.3/site-packages/Django-0.95-py2.3.egg/django/db/models/query.py",
line 88, in __repr__
return repr(self._get_data())
File
"/usr/local/lib/python2.3/site-packages/Django-0.95-py2.3.egg/django/db/models/base.py",
line 76, in __repr__
return '<%s: %s>' % (self.__class__.__name__, self)
File "/home/jmurray/prfa/../prfa/standings/models.py", line 88, in __str__
return "%s: %i (%i)" % (self.game.datetime.strftime("%Y-%m-%d"),
self.game.away.number, self.away_runs)
TypeError: int argument required
However when I retrieve an individual result...
>>> r=Result.objects.get(pk=234)
>>> r
>>>
This is confusing to me. __str__ works for an individual objects, but not
a collection of them. What's happening here?
I'm puzzled, I hope someone here is able to help me out.
BTW it is self.away_runs that causes the problems. When I remove that from
the __str__ function it works just fine.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users
-~--~~~~--~~--~--~---
SQL Queries with columns not in the DB
I'm reposting this because I was told my last post got lost in an existing thread. Sorry about that. I figured out my syncdb question. It turns out that as long as the model is defined correctly things go well. And the output from syncdb will help you with any trivial troubles you might have with your model. Nice! Another question for you all. I want to duplicate the queries that the existing app does. The site maintains the results, standings, and stats for a baseball league. It has queries like: select number, name, win, loss, tie, streak, streak_type, win/(win+loss+tie)*1.000 wpct, win*2+tie points, win+loss+tie GP, gamesinseason.games - (win+loss+tie) GL from stand_overall, gamesinseason, team where team.year = %s && gamesinseason.year = team.year && stand_overall.team = team.ID order by points desc, win desc, tie desc, loss and select First_name, Last_name, sum(ab) ab, sum(runs) r, sum(1b) s, s um(2b) d, sum(3b) t, sum(hr) hr, sum(hbp) hbp, sum(bb) bb, sum(ko) ko, sum(1b+2b+3b+hr) hits, (sum(1b)+sum(2b)+sum(3b)+sum(hr))/sum(ab)*1. avg, sum(bb)/(sum(bb)+sum(ab))*1. bb, (sum(1b)+sum(2b)+sum(3b)+sum(hr)+sum(bb)+sum(hbp))/(sum(ab)+sum(bb)+sum(hbp))*1. ob, (sum(1b)+2*sum(2b)+3*sum(3b)+4*sum(hr))/sum(ab)*1. as slug, sum(runs)/(sum(1b)+sum(2b)+sum(3b)+sum(hr)+sum(bb)+sum(hbp))*1 . score, sum(ko)/(sum(ab)+sum(bb)+sum(hbp))*1. kperapp from player, offensive_stats, game where player.ID = offensive_stats.player && game.ID = offensive_stats.game && player.First_name = %s && player.Last_name = %s group by First_name, Last_name My question revolves around how I should get similar results in django. From what I can tell I should be subclassing a Manager so I can return my own QuerySets. I don't think the writing custom SQL with connection.cursor() is the way to go. I know that the join portions of the where clauses will be taken care of by the db_api. I also know that I can do ORDER BY and LIMIT type stuff with extra=, .order(), etc. Am I on the right path? -- | Jason Murray -- | The problem in living with popular culture is maintaining some degree of | individuality - some sense of who we are and what we think in a world | in which so many others are trying to determine those things for us. -- Gary Bauslaugh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Extending the SQL
Another question for you all. As soon as I get my model.py ironed out for my existing DB I'm going to starting using the python db interface to see if things look good. Which means of course that I'll want to duplicate some of the queries that the existing app does. The site maintains the results, standings, and stats for a baseball league. It has queries like: select number, name, win, loss, tie, streak, streak_type, win/(win+loss+tie)*1.000 wpct, win*2+tie points, win+loss+tie GP, gamesinseason.games - (win+loss+tie) GL from stand_overall, gamesinseason, team where team.year = %s && gamesinseason.year = team.year && stand_overall.team = team.ID order by points desc, win desc, tie desc, loss and select First_name, Last_name, sum(ab) ab, sum(runs) r, sum(1b) s, s um(2b) d, sum(3b) t, sum(hr) hr, sum(hbp) hbp, sum(bb) bb, sum(ko) ko, sum(1b+2b+3b+hr) hits, (sum(1b)+sum(2b)+sum(3b)+sum(hr))/sum(ab)*1. avg, sum(bb)/(sum(bb)+sum(ab))*1. bb, (sum(1b)+sum(2b)+sum(3b)+sum(hr)+sum(bb)+sum(hbp))/(sum(ab)+sum(bb)+sum(hbp))*1. ob, (sum(1b)+2*sum(2b)+3*sum(3b)+4*sum(hr))/sum(ab)*1. as slug, sum(runs)/(sum(1b)+sum(2b)+sum(3b)+sum(hr)+sum(bb)+sum(hbp))*1 . score, sum(ko)/(sum(ab)+sum(bb)+sum(hbp))*1. kperapp from player, offensive_stats, game where player.ID = offensive_stats.player && game.ID = offensive_stats.game && player.First_name = %s && player.Last_name = %s group by First_name, Last_name My question revolves around how I should get similar results in django. From what I can tell I should be subclassing a Manager so I can return my own QuerySets. I don't think the writing custom SQL with connection.cursor() is the way to go. Am I on the right path? Again thanks in advance. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
inspectdb
I have an existing cgi based app that I'm starting to move over to django. I'm looking forward to seeing just what django can do for me. Since the DB has quite a bit of data and I'd like to avoid recreating the DB model in django and moving the actual data, I've elected to use the ispectdb feature. But, I have some questions. I've already run 'python manage.py syncdb' Then I ran 'python manage.py inspectdb' I notice that inspectdb picks up the auth tables. I'm assuming I can get rid of those in generated models.py file. Am I correct in this assumption? The inspect didn't pick up any of the FKs that M2M's that I have, which I expected since MySQL doesn't really explicitly record that information. So I'll be adding those next. My main question is when I get the models.py file to match the existing DB, what do I do next? The documentation says I should syncdb or init. When I do this will django blow away any existing data, or will it keep what is already there since the models.py will match what it sees in the DB? Thanks for your help. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: FileFields, MEDIA_ROOT, and private media
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > 1) Create two separate media directories: /media/public and > /media/restricted > 2) Configure Apache to serve /media/public directory directly > 3) Configure Apache to serve the /media/restricted directory using > mod_python > 4) Set a url entry in urls.py to e.g.: > > (r'^media/restricted/(?P.*)','myproject.myapp.views.view_restricted_media') > 5) Create view_restricted_media as: > @restrict_to_superuser > def view_restricted_media(request,path): > return static.serve(request,path,RESTRICTED_MEDIA_DIR) Thanks; I'll probably end up doing something very much like this. The only thing I'm not crazy about with this solution is that it is a little intensive on the webserver configuration; I prefer to make the webserver configuration as simple as possible and do more complex things on the application side. In this case, it's not too bad; I'll just have to document it adequately. Thanks again. -- +-------+ | Jason F. McBrayer[EMAIL PROTECTED] | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it.-- Dogen| --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: FileFields, MEDIA_ROOT, and private media
"Adrian Holovaty" <[EMAIL PROTECTED]> writes: > Are you using the Django admin for the file uploads? If not, you can > just write your own views that upload the data to a place of your > choosing. You'd be dealing with request.FILES for this. Unfortunately (?), I am using the Django admin for the file uploads -- they are (potentially private) attachments to a wiki-like model, and I'd like to leverage the admin for as much as possible. Another possibility that occurs to me would be to use mod_rewrite to redirect-away requests for that subdirectory of MEDIA_ROOT, but on the other hand, I'd like to be as webserver-agnostic as possible. -- +---+ | Jason F. McBrayer[EMAIL PROTECTED] | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it.-- Dogen| --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: Tagging app
Sounds great, I'd love to see this added. Regards, Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: Model Inheritance
On Fri, 2006-05-05 at 15:06 -0600, Joseph Kocherhans wrote: > That sounds about right. I've been developing a new authentication > system for django since PyCon that allows for different or even > multiple backends... the api has been pretty unstable so far, but it's > getting close. I've written some docs, but I'm sure they could use > some more work. Now that magic-removal has been merged I'm going to > request a branch to finish it up. If you're interested in going that > route and providing feedback, I'll speed up my efforts. I have a patch > available you could use, but maintaining a patched version of django > is a PITA to put it lightly. I would be interested in this, and in following the branch and providing feedback and possibly patches. I'd also be willing to work on docs. > > Does it make more sense to base this project on the Floating Sargasso > > branch, or to take one of those desperate measures? > > That would also work. It'd be better than mokeypatching IMO. If you > aren't using the admin system you're probably best off just rolling > your own authentication. In the long run, basing the project on Floating Sargasso is probably not sustainable. Doing my own auth would not be hard, and would work fine for the main app, since regular users will not be using admin functionality. However, they will, probably, be using various apps integrated into one site, so it just makes more sense to be using django authentication --- in the best case, I'd have to duplicate everything associated with django authentication (like DjangoContext putting request.user in the context), and in the worst, I'd have to do that plus modify various (possibly third-party) apps to use it instead of django auth. Let me know when and how I can help on the new-auth branch. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: Model Inheritance
"Joseph Kocherhans" <[EMAIL PROTECTED]> writes: > Yeah, it hasn't been implemented yet. I'd be (pleasantly) surprised to > see it finished before the end of the summer. Your best bet is to use > ForeignKey and/or OneToOneField. It's probably not exactly what you > want, but it should work. Note that the semantics of OneToOneField are > going to change by the time inheritence is implemented, so you may > want to use ForeignKey instead. This is kind of painful for me, since one of my projects depends on overriding auth.User (to do ldap authentication). I've been putting off my update to MR in order to think about what I want to do about this. It seems like for now my main options are to implement my own authentication scheme that doesn't integrate fully with Django's and which doesn't work with the auth pages (not _terribly_ important for this particular project), or to monkeypatch auth.User anywhere it might be used (evil). Is that true, or is there something that I'm missing? Does it make more sense to base this project on the Floating Sargasso branch, or to take one of those desperate measures? -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: session auto-logout
"sam" <[EMAIL PROTECTED]> writes: > A newbie question: > > I am using Django admin's authentication to do login/logout for my own > application. I want to automatically log user out if no activity for 5 > minutes. I read the session tutorial and played a bit with > SESSION_COOKIE_AGE -- but it doesn't work for me. Any suggestion > appreciated. Are you sure SESSION_COOKIE_AGE isn't working for you? It won't automatically redirect them to an unauthenticated page when their session is expired, but their next request should hit @login_required and redirect them. Also, if they already had an old session, it will have the default long expiry time. You may wish to flush the core_sessions table and see if it's working for you afterwards. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: Multi-page forms
"Chetan Vaity" <[EMAIL PROTECTED]> writes: > I want to build a two-page form for creating an object. As I see it there are > two options: > 1. Store values in hidden fields > 2. Use the session to store the variables from the first form > > Any Django best practices? I'd say use the session to store the values from the first form. If you use hidden fields, they could be modified by the user after submitting the first page. That would just mean that you'd need to do all your validation in the view handling the second page, but for UI reasons you probably want to do validation of a field on the page where the user actually entered it. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: only show something(form) if javascript-enabled
On Tue, 2006-02-21 at 23:52 +0100, gabor wrote: > i wanted to have in the user-manager form a way to do the normal > password-thing (2 password fields, check if they are equal, and so on). > > so, i created a page-template, put it to the right place so that it > overrides the django-users-manager template, > and started some javascript hacking :) > > i added the password fields to that page, and used javascript to: > -when submitting: check if the 2 passwords are equal, and if they are, > calculate the password-has, set it into the password-hash input-field > (which i made hidden), and allow the form to be submitted. otherwise do > not allow the form to be submitted. Don't do that. Calculate the password hash on the server side. You're trying to do something in the template that ought to be done in the view. So write a view that does what you want, rather than trying to use client-side code to generate stuff to be sent to an existing view. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: only show something(form) if javascript-enabled
Gábor Farkas <[EMAIL PROTECTED]> writes: > > at the end, i did the followin: > > - no javascript-visibility tricks > - the form's submit buttons are written out using document.write > - i added a tag to warn the user to enable javascript > > this way, if javascript is disabled, the user cannot submit the form. he > can still see it, but cannot submit (so cannot break anything). Unless they, say, save it to disk, edit it, reopen it, and submit the form. Which would be a perfectly logical thing for a user to do when presented with a trivially broken form that they legitimately want to submit. I know you know that you can't rely on client-side validation, but I just want to say, you _really_ can't rely on client-side validation. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: only show something(form) if javascript-enabled
gabor wrote: > so is there a way to only show some part of the webpage (or the whole > webpage) if javascript is enabled? Use javascript to build up the form and its visual elements on pageload. A user without Javascript enabled would see a blank page. :-) -Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: Please help with django tutorial #2
Sounds like you haven't done `python manage.py install polls` Regards, Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: editing multiple records
Patrick, I'm using Django right now for my in-house Finance department to "bulk" edit multiple items. You'd be surprised how I'm doing it, though. I'm generating an XML file and letting the user download it from the website... Then they use Excel for the "bulk editing", save again as XML, and repost back to the server. I'll document blog/this when I'm done. I *could* try to emulate the bulk editing features of a spreadsheet with something like TrimSpreasheet (http://trimpath.com/project/wiki/TrimSpreadsheet), and I hope to do that someday... but those "real world" finance dept. employees prefer the Excel interface... So "let them have cake", I say! By limiting the use of Excel to its strong GUI features for bulk editing (filters, sorting, searching, etc). I get the best of both worlds. And after the users are done, the results get posted back to a nice, clean, normalized relational database. No yucky spreadsheet files with massively important un-auditable data lying around on everyone's hard drives. Everyone's happy, and best of all Django makes this pretty darn easy to do, with the help of ElementTree for the XML. - Jason (First posted as a reply here-->http://www.jacobian.org/2006/jan/27/why-django/ )
Re: truncate html filter?
Adrian Holovaty <[EMAIL PROTECTED]> writes: > On 2/8/06, Milton Waddams <[EMAIL PROTECTED]> wrote: >> I'm wondering if anyone has a filter which safely truncates html so as >> not to chop through tags. > > Hey Milton, > > You could try using the Python interface to HTML Tidy: Beautiful Soup (http://www.crummy.com/software/BeautifulSoup/) might also be something to look at for this. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: login via url
On Wed, 2006-02-08 at 06:04 -0800, [EMAIL PROTECTED] wrote: > Does someone have a recipe for logging in via url only. I would like > to have it work with admin or regular user where > credentials can be passed as parameters in a url and they are logged in > and directed to the url. For admin login I am wanting it to simply log > into admin index. You _could_ do this by looking at the admin interface's login view, and handling request.GET the way it handles request.POST. But IMO you _shouldn't_ do this, as it may (depending on other things) open up quite a few new ways to steal credentials (think about referrers, and about httpd logs). -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: memory usage
On Wed, 2006-02-08 at 13:36 +0530, Kenneth Gonsalves wrote: > i have three django sites on a box. It is virtual hosting. The > active memory allotted is 75MB. I am getting complaints that i am > exceeding this memory. What can be done? as far as i can see, each > time someone accesses the site, a new httpd process is started > which takes up about 12 mb - 6 hits and the memory is exhausted It will probably take more specific information to answer this. What is the webserver (apache, lighttpd, other), and what method are you using to connect django to it (mod-python, fast-cgi, scgi, other)? If fast-cgi, how is your program started (apache mod-fastcgi process manager, or standalone)? All of those could have some impact on memory usage. Also, according to another recent thread on this list, DEBUG=True significantly increases memory usage. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: Memory leaks in DB API
Hi, Dody, Yes, I did see your reply. However, since I didn't see a public reply saying "Yes, that's it. Thank you!". I assumed that your reply wasn't the final solution and the thread was still open. Did Vidar reply to you saying this was indeed the solution? This subject line and the mention about running out of memory in the original post caused a knee-jerk "Yikes!" reaction for me, based on my all-too-real experiences with memory leaks. I'll try to take a deep breath and relax the next time I see "memory leak" in a Django thread. Unless of course, it's about a very real memory leak. Django-ly Yours, - Jason
Re: Memory leaks in DB API
Good to know. Then I stand corrected. But I guess this proves the point that I *still* don't know what the heck is causing my very real and very "now" memory leak problems in my Plone app :-) (And I should probably switch my rant to the Plone boards, not here). I like to think to that I'm relatively smart guy, but tracking down memory leaks in Python truly humbles me. -Jason
Re: scale of auth system
Luke Skibinski Holt wrote: > there is no per-record permission system > for users yet (or ever...). However this seems an unlikely scenario and > more often as not you will only want your users only looking/updating > data they have created. I had an "aha!" moment on this topic last night. My reply here should probably be cross-posted to the dev list, since it's more "dev" in focus and not very helpful from a "user" perspective (yet). I believe the solution to adding this type of "fine grained" security where users can only view/update data they have personally created can be solved by what others call "row level security". It basically comes down to appending a special "where" clause to any database query in order to limit the amount of data retrieved or edited. I'm thinking a Django-ish definition of this "where" clause can be added as a parameter to the admin clause in the Meta section of Django model. Here is a link at how row level security is defined in an Oracle database: http://www.securityfocus.com/infocus/1743 I'm now abstracting that out and figuring out how to apply this at the Python/Django layer so it is available for all database backends, not just Oracle. On a side note, months ago, I made a proposal on the Django dev list for an "ACL-like" permissions scheme to enable the level of fine grained permissions that I wanted. Now I've seen the error of my ways (that a globally generic ACL system is over-engineering the problem) and believe implementing some version of row level security is the way to go. Some facts and examples to back up this belief is that the Rails framework doesn't provide any complicated ACL system out of the box. My "aha" moment came while reading two innocuous paragraphs in the chapter titled "Securing your Rails Application" (21.5) from the book, Agile Web Development in Rails. excerpt 1: """ An attacker might notice this URL and attempt to view the orders for other customers by manually entering different order ids. We can prevent this by using a constrained find( ) in the action. In this example, we qualify the search with the additional criteria that the owner of the order must match the current user. An exception will be thrown if no order matches, which we handle by redisplaying the index page. """ and exerpt 2: """ Another solution to this issue is to use associations in your application. If we declare that a user has_many orders, then we can constrain the search to find only orders for that user... """ The authors don't say the phrase "row level security", but that's exactly what it is. Some critiques to my ACL proposal argued for the example in exerpt 2. I now happen to agree with them. :-) -Jason
Re: Memory leaks in DB API
I don't know what is wrong in this particular scenario.. but all I have to say is Memory leaks should be taken very seriously and should be hunted down and exterminated with extreme prejudice. Yes, Python has built-in garbage collection, but is way to easy to create circular references between objects (parent references child, child references parent)... Once that circular reference is created between two objects, the objects will never be garbage collected by Python, and thus, a memory leak is born. If the code that spawns those circular references gets called over and over again (very common if its part of SQL read/writes), the problem won't get "fixed" until the app uses up all available RAM in the OS, crashes, and a system admin (or script written by the admin) "reboots" the app to start the cycle all over again. There is nothing worse than a slow memory leak that uses up all your system memory over the course of days, weaks, (even months depending on usage) and eventually crashes your site and/or your OS. (This is happening to me now with a Zope/Plone app of mine.) The problem is so hard to find, debug, and fix, that my current solution is to simply reboot my Plone app every week to "fix" the memory leak problem. Very crufty and I hate it. The best solution for fixing memory leaks is prevention and early detection. ... and treating them like the evil cancer cells that they are. On that note, good luck, and have a nice day! :-) - Jason
Removing the Magic Branch release schedule
Hi Guys, I have just realized how awesome having multiple inheritance will be, so I am wondering if there is a guess at a release date for Django 0.92? I guess I just try out the branch itself until the release is made. Thanks for all your hard work! Jason Pepas
Re: Do I use @login_required to extend authentication?
Hmm... Jason, your code is probably the "next logical step" for my hack. The following is the right link to your code, yes? -->http://www.carcosa.net/jason/blog/computing/django/authentication-2005-12-05-13-25.html -Jason
Re: Do I use @login_required to extend authentication?
>You do mention that every entry in LDAP must also exist in the > django users table as well - is that a fundamental requirement? Yes, it is a fundamental requirement for my "hack". I put "hack" in quotes because I fully admit that my patch is not a complete plug-in replacement for Django's user model. I'm only using LDAP for what most people use it for-- checking passwords. Since, I'll only have about 6-8 users using my app, I personally don't have a problem duplicating these accounts in Django's database. I still want to keep Django's auth tables for linking users to groups and permissions. To automatically keep the Django database in sync with LDAP, I'll most likely create an "add/remove" python script that polls LDAP and syncs up the user table in Django by adding or removing (or perhaps disabling) accounts as needed. Perhaps the better approach is to completly remove the dependency on the Django user table. But making LDAP a complete replacement would take more work, which I don't need at this point, so I avoided doing it. -Jason
Re: Do I use @login_required to extend authentication?
"tonemcd" <[EMAIL PROTECTED]> writes: > You do mention that every entry in LDAP must also exist in the django > users table as well - is that a fundamental requirement? I've written very similar django-to-ldap glue code to this, and what I did was treat the django User model as a cache of data in ldap. I have a login view that, if a matching django user cannot be found, but ldap authentication succeeds, creates the django user, then imports information about them into the User object from ldap and saves the user. The user object could be deleted on logout, or periodically by a grim record reaper but I haven't found that necessary yet. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: Oracle support?
I wrote the patch using Oracle 9.2.0.1.0 on Windows XP and Python 2.4.1. I'm hoping to set up a dev server (or at least VMPlayer image) that will test the patch against Windows and Red Hat versions of Oracle 10g. I highly doubt there are version specific differences in the patch between 9i and 10g, but I'm wise enough to know that I should expect the unexpected. :-) -Jason
Re: Do I use @login_required to extend authentication?
tonemcd wrote: > Amit, > *Many thanks* - that is *exactly* the kind of stuff I need to know > about. We have people who can write the decorators for LDAP > authentication, I just wrote a detailed post on how to "hack" in LDAP support to Django. It does not cover the same steps as suggested by Amit, but it took me less than an hour to complete, and there are very, very few lines of code involved. "Hacking in LDAP support to Django" : http://www.jrandolph.com/blog/?p=22 Enjoy, Jason
Problem using a related object in __repr__()
Hi, I am trying to use a related object's attribute as part of the __repr__() function, and am running into trouble. from django.core import meta class Foo(meta.Model): name = meta.CharField(maxlength=255) def __repr__(self): return self.name class META: admin = meta.Admin() class Bar(meta.Model): name = meta.CharField(maxlength=255) foo = meta.ForeignKey(Foo) def __repr__(self): return self.name + " " + self.foo.name class META: admin = meta.Admin() With this setup, I can create a Bar in the admin page, but when I hit "submit", it throws an exception. Unfortunately the exception gets clobbered, but I added a quick one-liner hack to print it out before it gets clobbered, and this is the error: 'Bar' object has no attribute 'foo' What am I missing? Thanks, Jason Pepas
multiple inheritance?
hi, I want to do something like this: from django.core import meta class Tag(meta.Model): text = meta.CharField(maxlength=255) def __repr__(self): return self.text class META: admin = meta.Admin() class Taggable(meta.Model): tags = meta.ManyToManyField(Tag, blank=True) class Note(meta.Model): text = meta.TextField() def __repr__(self): return self.text class META: admin = meta.Admin() class Noteable(meta.Model): notes = meta.ManyToManyField(Tag, blank=True) class Foo(Taggable, Noteable): name = meta.CharField(maxlength=255) def __repr__(self): return self.name class META: admin = meta.Admin() but the result is only taggable, and not noteable. Any ideas? thanks, jason pepas
Re: Guido on Django
Yeah, my thoughts exactly on the turbogears thing... I like Rails, Django, and gosh, even Plone, specifically because they're used in large, referenceable, high-traffic *production* sites. The Rails gang are very handy about documenting knowledge of their production support and deployment tips and tricks (SwitchTower being a good example). When you have real, high traffic sites, you get lots of googleable tidbits of knowledge from folks on how to tune and fix and deploy the framework. Since TG is so new, my impression (though I could be wrong) is that there is very little googleable knowledge about using it and tuning it in a production environment. On that note, TG's components, howerver, have been around for a while, so I'd more inclined to roll my own "framework" of CherryPy, SQLObject, and Cheetah in production than use the current TG. Of course, my opinion of TG will probably change once other trail blazers document their use of TG on a high traffic site. :-)
Re: magic_removal table update
Max Battcher wrote:
> I'm living on the bleeding edge (just migrated to rev. 2123) with my
> current development, and followed the suggested ALTER TABLE commands
> from the wiki page, and though I can read from the data (all of the
> views work correctly), I can't save because all of the sequences are now
> out of sync. I tried renaming the sequences to fit the new naming
> scheme, but to no avail (Django is calling the new sequence name and the
> table itself still refers to the old sequence name).
Yeah, you need to do something like:
ALTER TABLE auth_groups_id_seq RENAME TO auth_group_id_seq;
ALTER TABLE auth_groups ALTER id SET DEFAULT
nextval('public.auth_group_id_seq'::text);
...for each sequence that needs renaming.
Regards,
Jason
Re: Adding ManyToMany relationships
On Wed, 2005-12-07 at 05:35 -0800, quentinsf wrote: > OK, I've found the code, and it looks as if set_FOOs() does intelligent > things about only updating the *changes* to the list of object IDs. > I'll use that for now. > > Add and Delete methods would be nice though, as would something that > takes objects instead of IDs. Seems more Djangoesque. (Is that a > word?) I've also been missing add/delete methods. The app I'm writing/using uses a ManyToMany relationship to keep track of what articles each user has read. Adding to this list is a little slow, at least partly because the whole list must be fetched and updated before set_FOOs() gets called. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: ANN: Django site on washingtonpost.com
On Mon, 2005-12-05 at 21:20 -0600, Adrian Holovaty wrote: > Check it out: The first Django app at washingtonpost.com! > > The U.S. Congress Votes Database > http://projects.washingtonpost.com/congress/ > > It lets you browse every vote in the U.S. Congress since 1991. Very useful, and the RSS feeds could be a very handy tool for activists. One thing -- the RSS feeds would be a lot more useful if they included the bill and the vote description -- the Question field is not very informative without that, and right now it's the only thing besides Yes or No in the entry afaict. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: E-Commerce / Credit Card Processing
On Wed, 2005-11-30 at 17:51 -0800, Joshua D. Drake wrote: > We will actually be writing a class for PayFlowPro here in a couple of > weeks. I am sure > we could share. I would be very interested in this, as well. Are you translating their PHP or Perl code from the developers kit, or taking some other approach? -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: New-admin problem
Which revision are you using? I think rjwittams fixed it in revision #1159. --Jase
Re: redirecting subdomain requests
On Sun, 2005-10-16 at 14:27 +, Alice wrote: > I'm just learning regular expressions (something I've put off for ages > now), and was wondering if it was possible to redirect from a subdomain > to somewhere within my project using Django, i.e. > > redirect 'Subdomain.domain.com.au/appname/' to > 'domain.com.au/appname/pagename' > > or is this better suited to mod_rewrite? (something else I've put off > learning about) You could put an app at subdomain.domain.com.au/appname/ with an index view that just returns HttpResponseRedirect. But learning just enough about mod_rewrite to do the job would probably be less work. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: big drop-down lists, raw_id_admin and custom primary key: a bug?
Adrian Holovaty wrote: > Oooh, that's a good idea. Django already displays the __repr__() of > the corresponding record on the *change* page, but it'd be nice to do > it automatically (via Ajax) right after the field is populated on the > add page (or changed on the change page). Yup... I noticed this bug, too. This was on my "list of small bugs that I need to fix and submit patches for". :-) Don't forget also... if the pop up selector is used to select the code, it should update the __repr__ *and* the code displayed in the form. Right now, it updates the selected, but does update the __repr__ until the page is saved... It's quite confusing. -jason
Re: Problem/questions about generic views
PythonistL wrote:
> urlpatterns = patterns('',
> (r'^list/(?P\d+)/$',
> 'django.views.generic.list_detail.object_list',info_dict),
> )
>
>
> is it possible to use ,for example,
> /list/3/
>
> to move to page 3
This doesn't work because object_list doesn't take a keyword argument
for 'page'. The page number is retrieved from a GET parameter instead.
If you get rid of (?P\d+)/ and use ?page=2 at the end of your
URL it should work.
Regards,
Jason
Packaging django apps
Hi. I've more-or-less finished a django app that might be useful to other people --- it's a feed reader similar to feedonfeeds, except that it is multiuser, supports categories, and is more tolerant of invalid feeds (thanks to the wonderful feedparser -- feedparser.org). It's basically functionally complete (I now use it instead of feedonfeeds), though it still has a few rough edges and is missing some less-used views. I'd like to package this for other people in a way that is as convenient for them as possible, while not requiring too much work from me. So, what do people expect from a third-party django app by way of packaging? Just a tarball of the app and templates directory? Install scripts? README, COPYING, and INSTALL documents? -- ++ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: internal_error.html?
On Mon, 2005-09-05 at 18:50 -0500, Eugene Lazutkin wrote: > Yep. It depends on size. It seems that web server sends the first part of > page up to some limit and stalls for a while. After that it may send the > rest or append "internal_error.html" nonsense. > > Now I have to figure out who is the culprit: Apache, FastCGI server, Django > (e.g., FastCGI portion of it), or some weird interaction of all of them. My > bet is it is not Django, but who knows... I have had a similar problem with django under fcgi (using the fcgi-wsgi connector from flup). On longer pages, most of the page is sent, then it stalls until mod_fcgi times out listening to the fcgi-server, then sends the rest of the page. I have found a workaround for this, which is to use flup's gzip middleware like so: django-fcgi.py: -- #!/usr/bin/python from flup.server.fcgi_fork import WSGIServer #from flup.server.fcgi import WSGIServer from flup.middleware.gzip import GzipMiddleware from django.core.handlers.wsgi import WSGIHandler handler = WSGIHandler() handler = GzipMiddleware(handler) WSGIServer(handler).run() This prevents the stalls, at least for browsers that support gzip encoding! I am not, at this time, sure where the problem lies; whether it is in django's WSGI interface, in flup's fcgi-wsgi adapter, or in Apache's mod_fcgi. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: initial data
On Thu, 2005-09-01 at 10:15 +0100, Rachel Willmer wrote: > is there a django way to set up the tables with the initial data I > want? or should I just do this using a postgres script? You could either do it with a postgres script, or you could write a python script that imports your models, instantiates objects, and saves them. Or, of course, you could use the admin interface, but that would quickly get tedious. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: Storing models in sessions
On Wed, 2005-08-31 at 14:28 +0400, Maniac wrote: > I use Django's model objects to store a users environment. It's not just > some options like prefered color or something instead it's a full blown > model. To be specific it's an application for ordering printing of > digital pictures. The users environment consists of a desktop with image > thumbnails, thumbnails know their position on the desktop, and also > store all the printing parameters like paper type, size, special framing > etc. > > Speaking generally I wonder how (or wether) Django's sessions are > suitable to store such rather large structured data. I think you would be better off storing the model objects as usual, but adding a couple of flags to your model: one to indicate that this object is a temporary/unregistered user, and one to store when the object should be expired. You can then either periodically do batch expiry, or some other system. I assume that once no sessions refer to one of those users anymore, having an inactive temporary user model hanging around doesn't cost you anything except database space which you can reclaim when it's convenient. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: User Authentication - What's the best way?
equest.path) except (KeyError, users.UserDoesNotExist): return redirect_to_login(request.path) return _checklogin A typical view function will be decorated with login_required like so (as I'm using python 2.3): def view(req): blah blah blah... view = util.login_required(blah) > Anyone point me in the right direction? Or even a breif explanation of > how django's admin authentcation works might get me going. I arrived at this solution by looking at the anonymous session documentation and the admin code. If my code samples don't help, you might want to look there, too. Good luck! -- ++ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: Basic file upload (not model file object)
On Tue, 2005-08-30 at 03:32 -0700, Dagur wrote:
> It took me a while but I figured out how to do this:
>
> if request.POST:
> new_data = request.POST.copy()
> new_data.update(request.FILES) # This has to be added
>
> errors = manipulator.get_validation_errors(new_data)
> if not errors:
> new_message = manipulator.save(new_data)
> return HttpResponseRedirect("%i/" % new_message.id)
Thanks for the response. My problem actually turned out to be a hard-
to-spot typo in my template. The "enctype" on the form was
"multipart/form_data" rather than "multipart/form-data". Too much
typing python, I guess ;)
Thanks, all, for the response. As I said, I knew it had to be something
stupid.
--
+----+
| Jason F. McBrayer [EMAIL PROTECTED] |
| "If you wish to make Pythocles wealthy, don't give him more |
| money; rather, reduce his desires."-- Epicurus |
Re: Basic file upload (not model file object)
On Mon, 2005-08-29 at 20:04 -0700, Leonardo Santagada wrote: > Just guessing, but in python strings are byte arrays, so I don't think > there is any error in that. Or maybe there is a problem with the form > sending the content and the validator expecting a filename, or the > inverse. > > Just my 2 cents, and as noone answered this I thought it may help The problem seems to be that the validator isn't expecting a string. I assume that it is not a bug with the validator (or else it would have been noticed, since it is the built-in validator on the standard FileUploadField), but somewhere else, either in my template or my view, but I am unable to find the problem (so far). Thanks for the input. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Basic file upload (not model file object)
I'm almost certainly missing something very, very simple here, but I haven't been able to find what it is on my own. One view in my app should allow users to upload an OPML file, which the app will parse and use to import feeds, but which won't otherwise be stored. As with most other non-model-based forms, I'm using a custom validator for this form: class AddFromOPMLManipulator(formfields.Manipulator): def __init__(self): self.fields = ( formfields.FileUploadField(field_name="opml_file", is_required=True,), ) When the form is submitted, I get this traceback: Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/handlers/base.py", line 64, in get_response response = callback(request, **param_dict) File "/home/jmcbray/Documents/topical/business/site_test/apps/engulf/views/util.py", line 231, in _checklogin return view_func(request, *args, **kwargs) File "/home/jmcbray/Documents/topical/business/site_test/apps/engulf/views/engulf.py", line 333, in add opml_errors = opml_manipulator.get_validation_errors(opml_data) File "/usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/formfields.py", line 70, in get_validation_errors validator(new_data.get(field.field_name, ''), new_data) File "/usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/formfields.py", line 491, in isNonEmptyFile if not field_data['content']: TypeError: string indices must be integers The form enctype is multipart/form-data. Obviously the value of the field the validator is seeing is a string, and obviously it shouldn't be. So what's going wrong here? It's surely something that should be completely obvious, but somehow I'm just managing to miss it. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: IMPORTANT: Django model syntax is changing
The new syntax breaks get_list() for me. Here's an excerpt from my
model:
class Category(meta.Model):
name = meta.CharField("Name of Category", maxlength=255)
user = meta.ForeignKey(User)
feed = meta.ManyToManyField(Feed, filter_interface=meta.VERTICAL)
class META:
admin = meta.Admin()
def __repr__(self):
return self.name
class User(meta.Model):
username = meta.CharField('Username', maxlength=64, unique=True)
password = meta.CharField('Password', maxlength=64)
feed = meta.ManyToManyField(Feed, filter_interface=meta.VERTICAL,
null=True, blank=True)
class META:
admin = meta.Admin()
def __repr__(self):
return self.username
def check_password(self,password):
if password == self.password:
return True
else:
return False
And here's what fails (in an ipython session, to demonstrate):
> In [1]: from django.models.engulf import feeds, users, articles, categorys
> In [2]: c = categorys.get_list(user_id__exact=1)
> ---
> TypeError Traceback (most recent call last)
>
> /home/jmcbray/Documents/
>
> /usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/utils/functional.py
> in _curried(*moreargs, **morekwargs)
> 0 return _curried
>
> /usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/meta/__init__.py
> in function_get_list(opts, klass, **kwargs)
>1118
>1119 def function_get_list(opts, klass, **kwargs):
> -> 1120 return list(function_get_iterator(opts, klass, **kwargs))
>1121
>1122 def function_get_count(opts, **kwargs):
>
> /usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/meta/__init__.py
> in function_get_iterator(opts, klass, **kwargs)
>1100
>1101 cursor = db.db.cursor()
> -> 1102 select, sql, params = function_get_sql_clause(opts, **kwargs)
>1103 cursor.execute("SELECT " + (kwargs.get('distinct') and "DISTINCT
> " or "") + ",".join(select) + sql, params)
>1104 fill_cache = kwargs.get('select_related')
>
> /usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/meta/__init__.py
> in function_get_sql_clause(opts, **kwargs)
>1297
>1298 # Convert the kwargs into SQL.
> -> 1299 tables2, join_where2, where2, params2, _ =
> _parse_lookup(kwargs.items(), opts)
>1300 tables.extend(tables2)
>1301 where.extend(join_where2 + where2)
>
> /usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/meta/__init__.py
> in _parse_lookup(kwarg_items, opts, table_count)
>1287 _throw_bad_kwarg_error(kwarg)
>1288 except StopIteration:
> -> 1289 continue
>1290 return tables, join_where, where, params, table_count
>1291
>
> /usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/meta/__init__.py
> in _throw_bad_kwarg_error(kwarg)
>1176 def _throw_bad_kwarg_error(kwarg):
>1177 # Helper function to remove redundancy.
> -> 1178 raise TypeError, "got unexpected keyword argument '%s'" % kwarg
>1179
>1180 def _parse_lookup(kwarg_items, opts, table_count=0):
>
> TypeError: got unexpected keyword argument 'user_id__exact'
>
I've tried a few variations on the keyword argument, and can't seem to
find what it is now looking for. I regenerated the database from the
model (sqlreset) and populated it a bit, just to make sure that wasn't
it, but no joy. My django tree is at revision 559. Is anyone else
seeing this?
--
++
| Jason F. McBrayer [EMAIL PROTECTED] |
| "If you wish to make Pythocles wealthy, don't give him more |
| money; rather, reduce his desires."-- Epicurus |
