Re: Forking a background process on request

2010-11-05 Thread Elver Loho
Celery is exactly what I'm looking for! Thanks! :)

On 4 November 2010 13:41, Brian Bouterse <bmbou...@gmail.com> wrote:
> I would look into django-celery to do asynchronous tasks.  It can also be
> executed as a webhooks style, see here.
>
> Brian
> On Thu, Nov 4, 2010 at 3:31 AM, Elver Loho <elver.l...@gmail.com> wrote:
>>
>> Hi,
>>
>> I am working on a web app that creates reports that may take up to a
>> minute to generate. (Or longer under heavy loads.) Ideally I would
>> like something like this to happen:
>>
>> 1. User presses a button on the website. Javascript sends a begin-
>> report-creation message to the server.
>> 2. Report creation begins on the server in a separate process and the
>> called view function returns "ok".
>> 3. A bit of Javascript checks every ten seconds if the report is done.
>> 4. If the report is done, another bit of Javascript loads it into the
>> website for display.
>>
>> My question is - what is the best way of forking a separate process in
>> step 2 to start the actual background report generation while also
>> returning an "ok" message to the calling Javascript? Or do I even need
>> a separate process? What sort of concurrency issues do I need to worry
>> about?
>>
>> Reports are currently generated once every hour by a cron-launched
>> Python script. This is working splendidly.
>>
>> Best,
>> Elver
>> P.S: Django is awesome! I've only been using it for a couple of days,
>> but I gotta say, I've never been so productive with any other
>> framework of any kind.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django-us...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
>>
>
>
>
> --
> Brian Bouterse
> ITng Services
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

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



Forking a background process on request

2010-11-04 Thread Elver Loho
Hi,

I am working on a web app that creates reports that may take up to a
minute to generate. (Or longer under heavy loads.) Ideally I would
like something like this to happen:

1. User presses a button on the website. Javascript sends a begin-
report-creation message to the server.
2. Report creation begins on the server in a separate process and the
called view function returns "ok".
3. A bit of Javascript checks every ten seconds if the report is done.
4. If the report is done, another bit of Javascript loads it into the
website for display.

My question is - what is the best way of forking a separate process in
step 2 to start the actual background report generation while also
returning an "ok" message to the calling Javascript? Or do I even need
a separate process? What sort of concurrency issues do I need to worry
about?

Reports are currently generated once every hour by a cron-launched
Python script. This is working splendidly.

Best,
Elver
P.S: Django is awesome! I've only been using it for a couple of days,
but I gotta say, I've never been so productive with any other
framework of any kind.

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



Re: when is 1 != 1? (according to 'ifequal' in template)

2006-08-07 Thread Elver Loho

On 8/7/06, hotani <[EMAIL PROTECTED]> wrote:
>
> I'm doing a comparison of a session variable and an id for a 'selected'
> tag in a drop-down in a template. If I output both vars, they will both
> be "1" yet 'ifequal' is still returning false. Has water stopped being
> wet?

While water might be wet, "water" definitely is not :)

--~--~-~--~~~---~--~~
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: Django vs TurboGears

2006-07-29 Thread Elver Loho

On 7/29/06, Javier Nievas <[EMAIL PROTECTED]> wrote:
>
> Django does not use MVC model, it uses Model - View - Template (MVT)
> model. It's similar, because an MVC view is like an MVT template, and
> an MVC controller is like a MVT view.

http://en.wikipedia.org/wiki/Model-view-controller#Operation -- It's
the same thing, just with a different name.

But to be buzzword-compliant, let's call it an n-tier architecture! ;)

--~--~-~--~~~---~--~~
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: Django vs TurboGears

2006-07-29 Thread Elver Loho

On 7/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'm evaluating the possibility to use Django for a project, but I have
> read so many comments about Django vs TurboGears and right now I am
> very confused.
> I installed both of them in my system and sincerelly I found that
> Django is very easy to install and getting started while TG is not so
> easy.

Um. Last I checked, both have very clear installation instructions.
Besides, does install time really matter?

> Nevertheless I hesitate to trust on the Django semplicity against the
> TG complexity and I'm trying to examinate some characteristics in both
> of them that interest to me.

If you're comparing frameworks, you also might want to check out Zope.
I've tried Zope 3 myself and found it to be horrible and very
un-Pythonic, but a friend of mine has been writing web applications
with Zope 2 for a very long time and says that it's much better.

> Django gives you an admin environment for free while TG doesn't have
> such thing and I have no idea how to create it.

By writing code. Of course.

To be fair, TG has Catwalk, which works as a sort of makeshift admin
interface, but you'll have to write your own eventually, anyway, if
it's a complicated website you're building.

> TG applys the pattern MVC while Django does it in a strange way.

As many have said before, it's a matter of taste :)

> Django doesn't use AJAX while TG uses Mochikit and JASON.

...and what stops you from using Mochikit and JASON with Django? It's
like saying that you can't order ice-cream at McDonald's, because it's
not part of the Happy Meal you're eating.

> Django is very compact while TG is assembled with many moduls to put
> together.

Well, TG is pretty much a whole lot of Open Source tools and duct
tape. There are advantages to having a sort of a "guiding vision" as
with Django. Then again, as many things are a matter of taste, I've
found that being able to swap out bits is useful and TG is more
loosely-coupled, which makes it easier.

That said, I've used Django with several of its parts swapped out just fine.

I'm gonna do the ultimate geek thing here and compare web frameworks
to science fiction series. Django is like Babylon 5. It has a guiding
vision behind it and it's very coherent, very logical, with all the 5
seasons planned up front. (Except for the slight restructuring after
Bruce Boxleitner was brought in at the beginning of the 2nd season /
magic-removal clean-up of Django.) But TG is a bit like Star Trek --
there might be storylines that span a couple of episodes, but that's
it. Each episode is pretty much on its own and the "big picture" sort
of evolves over time. No real guiding vision / grand plot.

> Someone of you could give me a good reason to use Django instead of TG?

Set aside a weekend and write a simple application with both. Like,
say, a todo-list manager. Or if you hate having to deal with dates and
times, then write a very simple blog engine.

I'll give you a couple of reasons to use Django, which I myself found important.

* Caching framework. Simply awesome.
* Autogenerated admin interface is more advanced than the Turbogears
one. (Last I checked.) Still, you will have to write your own
eventually.

Um. That's about it. These are its clear, technical advantages over TG
-- I think everything else is just a matter of taste. I'm not really
qualified to say good or bad things about either of the frameworks,
really. I've used both and for the last big web application I built
(an admin interface for a distributed filtering application) I pretty
much rolled my own -- basically many of the components from TG, but
with much of the glue and unneeded parts removed.


Elver

--~--~-~--~~~---~--~~
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: Is Django the framework I've been looking for?

2006-07-20 Thread Elver Loho

On 7/21/06, Sean Schertell <[EMAIL PROTECTED]> wrote:
>
> Thanks for presenting a different angle.  I imagine you're one of
> these long-bearded guys who uses NetBSD and Fluxbox as his main
> desktop OS and edits code in VI through a tsch shell ;-)

Ubuntu Dapper and Gnome. (I need Unix on commodity hardware. I need it
with as little pain in the butt as possible.) SciTE for my code,
though, which is pretty much just glorified Notepad with syntax
hightlighting :P

Just because I like to reinvent a bike here or there for fun doesn't
mean I'm not lazy :P

> For me? OS X and TextMate plus some well thought-out framework that
> allows me to get from A to Z in __as little time as possible__. I'll
> re-invent stuff if necessary, but if there's some well-oiled machine
> that I can find to do exactly what I want, I'd much rather use that.
> Polish and cohesiveness are important to me. I'm allergic to "jalopy"
> solutions with various bits all taped and stapled together (cough -
> desktop Linux - cough). So for me personally, I think a framework
> born of a single vision such as Django or Rails is a better fit.

Yes. I, too, hate stuff that's duct-taped together. Which is why I
don't use TurboGears :)

Speaking of duct-tape, though. The various "magic" bits of Django
seemed, to me at least, to be somewhat duct-tape-ish. Yeah, it was
certainly useful being able to just set a variable and have it do
something cool that you need, but it made me scared of what extra
magic might be hiding under the hood that might bite me in the butt
later.

I think the law of leaky abstractions applies here.

I'm not saying Django's bad or flawed. It's just my preference. Plus
I'm by no means an expert on Django.


Elver

--~--~-~--~~~---~--~~
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: Is Django the framework I've been looking for?

2006-07-20 Thread Elver Loho

Allow me to offer a dissenting view. I recently faced the task of
finding a Python-based framework to use at work and tried several,
including Django. I finally settled on using CherryPy with Kid. (Which
is what TurboGears is doing, but with a lot of extra cruft thrown in.
And btw, the TurboGears mailing list is great for tech support on
CherryPy and Kid.)

On 7/21/06, Sean Schertell <[EMAIL PROTECTED]> wrote:
> Specifically what I'm hoping Django will do for me
> =
> (1) Portable apps across projects architecture. From what I've read,
> it sounds like a perfect fit for what I want to do. Is it really that
> great?

In CherryPy, every "directory" of the website is mapped to a class
with its exposed methods being the "files" in that directory. It's a
godsend as you can write any kind of functionality (shopping cart,
blog, whatnot) into a class or two and plop it anywhere else. Very
portable and versatile.

Django is somewhat more flexible (as you can map any function to any
path), but CherryPy's class/method way of mapping things suits me
better. It just seems more logical. Whereas Django allows you to
redefine logic if needed :P

> (2) Stable deployment with mod_python instead of some wonky FastCGI
> jalopy. Is it *really* stable -- enough for mission critical
> production environment? How about memory footprint? Can I run 100+
> Django sites on a shared server and expect smooth sailing?

CherryPy provides its own server by default, which according to the
CherryPy website is very stable, mature, and fast (with raw speeds
comparable to Apache) but I think it can be set up using mod_python.
Because Apache is faster for serving static files, we have CherryPy on
a soon-to-be-in-production site sitting behind mod_rewrite so that
certain folders are served by Apache.

> (3) I still get to keep most of what I love about Rails. Pure object-
> oriented MVC (MTV) development stucture, free stuff like form
> validation, code generation, pagination, input sanitization, etc. Is
> it true? What will I miss most about Rails?

If you want OO, then from what I've seen, CherryPy might be a much
better choice. As for free stuff, then Django certainly does all that
(except code generation) and TurboGears does all that, (except code
generation) but CherryPy alone does not.

You could use the form validation, input sanitizaion and other needed
tidbits from TurboGears. If you want them. (I really didn't need them
on our CherryPy system. I'm one of those people who likes to reinvent
bikes for fun :P)

> Sorry for the looong post. Any feedback at all would be very much
> appreciated!

Before anyone flames me, then I think Django is great. It's a lot of
fun to develop with and it's certainly a very capable framework with a
lot of interesting new features I hadn't seen before. But it just
didn't "click" for me. CherryPy seemed more mature, more stable, more
minimalistic, and certainly more in tune with my programming style.

But hey, I'm no expert :)


Elver

--~--~-~--~~~---~--~~
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: Weird behaviour

2006-06-07 Thread Elver Loho

On 6/8/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2006-06-08 at 02:21 +0300, Elver Loho wrote:
> > On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > >
> > > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > > > This behaviour is just way too weird. I'm currently developing with
> > > > Django for work and with CherryPy for a side project and CherryPy
> > > > doesn't store sessions beyond the lifetime of the server. I sort of
> > > > didn't expect this behaviour from Django either.
> > > >
> > > > So, this a bug or a feature? And how can I turn it off?
> > >
> > > Turn it off with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting.
> >
> > That simply sets the cookie to expire when the browser is closed.
> > That's not a solution since I've got Firefox open in 3-4 workspaces
> > here, with several tabs in each instance. I'm sure as hell *not* going
> > to close every last instance every time I change something in the code
> > and want to start all over again...
> >
> > I think it's a bug that Django's session variables survive when the
> > Django development server is closed. Yes, when I close the browser,
> > it's nice that I can start it again and be greeted with my session.
> > However, when I close the server, I expect the session to be lost.

> Move beyond the development server for a moment and think about sessions
> in the more general concept.

The point is, I'm doing this on the development server. It's the
*development* server. It's not Apache with mod_python. And in Django's
docs it is said that people should not use the development server for
anything but, well, development.

Everything you've just said makes a lot of sense on a production
rollout. Yes, do keep sessions after shutdown. It's a great feature!
But this "feature" on the development server simply makes development
more difficult.

So, um, could someone add a feature to the SVN version to let me turn
this off? Please? Pretty please? With sugar on top? :)


Elver

--~--~-~--~~~---~--~~
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: Weird behaviour

2006-06-07 Thread Elver Loho

On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > This behaviour is just way too weird. I'm currently developing with
> > Django for work and with CherryPy for a side project and CherryPy
> > doesn't store sessions beyond the lifetime of the server. I sort of
> > didn't expect this behaviour from Django either.
> >
> > So, this a bug or a feature? And how can I turn it off?
>
> Turn it off with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting.

That simply sets the cookie to expire when the browser is closed.
That's not a solution since I've got Firefox open in 3-4 workspaces
here, with several tabs in each instance. I'm sure as hell *not* going
to close every last instance every time I change something in the code
and want to start all over again...

I think it's a bug that Django's session variables survive when the
Django development server is closed. Yes, when I close the browser,
it's nice that I can start it again and be greeted with my session.
However, when I close the server, I expect the session to be lost.

How can I tell Django to store the sessions in memory and drop them
when the server is closed?


Elver

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



Weird behaviour

2006-06-07 Thread Elver Loho

request.session seems to be storing things beyond me closing the
Django development server. This is sort of weird. Is it a feature or a
bug? Because, I'd prefer a clean slate every time I run the devserver.


Example code:
def foo(request):

foo = request.session.get("foo", None)

print "foo is", str(foo)

if foo == None:
request.session["foo"] = "Haha! Not None!"

Behaviour:
# Server started
# First run: "foo is None"
# Second run: "foo is Haha! Not None!"
# Server closed

# Server started
# First run: "foo is Haha! Not None!"


This behaviour is just way too weird. I'm currently developing with
Django for work and with CherryPy for a side project and CherryPy
doesn't store sessions beyond the lifetime of the server. I sort of
didn't expect this behaviour from Django either.

So, this a bug or a feature? And how can I turn it off?


Elver

--~--~-~--~~~---~--~~
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: I think I'm doing something wrong...

2006-06-06 Thread Elver Loho

Darn, well, that fixed it :P

And to think I had the same problem with TurboGears a while bak. Sheesh.

Thanks, everyone! :)


Elver

On 6/7/06, Max Battcher <[EMAIL PROTECTED]> wrote:
>
> Elver Loho wrote:
> > 
>
> Sadly it seems you, along with so many, many others, have fallen into
> the easiest problem in the book.  Your action address should have a
> following /.
>
> http://code.djangoproject.com/wiki/NewbieMistakes#POSTtoviewslosesPOSTdata
>
> --
> --Max Battcher--
> http://www.worldmaker.net/
> "I'm gonna win, trust in me / I have come to save this world / and in
> the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track)
>
> >
>

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



Unhappy, reinventing

2006-05-24 Thread Elver Loho

I used to code stuff with TurboGears, which started sucking rather
fast. I still liked their templating engine, Kid. Sort of. I've also
tried Zope 3's and Django's, a couple of homegrown ones, Interchange's
as used on our big webstore and a bunch of others. As far as I'm
concerned, they all have fundamental design flaws.

I've outlined my problems with current templating solutions here:

http://elver.cellosoft.com/2006/05/24/acceptable-use-of-programming-in-templates/

I also look at some alternatives there, including one that I'm really
excited about. I think it could be integrated on top of Django rather
easily, but I'm not sure if my Python-fu is up to the challenge.

It's just my 2 cents, but, hell, I really really really dislike the
current choices.

Oh and the comments are moderated due to spam. And I'm sleepy. So
it'll take some time for them to show up.


Elver

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



Function caching

2006-05-23 Thread Elver Loho

Can Django's caching framework somehow be used to cache the output of
any function?

What I have right now is basically a standard Django project where
I've swapped out the templating engine and replaced it with Kid and
where I'm not using the supplied O-R mapper, but where I've written my
own DB layer.

The DB layer is basically just a db.py with each app that has a set of
functions for doing queries on the database. So I could do something
like:

from db import get_latest_books
books = get_latest_books(days=7)
blah.blah.output(template, books)

Some of the queries are rather expensive. Some might take a couple of
seconds to run. (There are 5.5 million books in the database...)

Does Django offer any decorators for caching the output of any
function, such as get_latest_books, based on the arguments passed to
it?

Or are there plans to include something like this? If not, then this
would be my request.


Elver

--~--~-~--~~~---~--~~
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: Transactions and model.save()

2006-05-16 Thread Elver Loho

On 5/17/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 5/16/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > Let's take the poll sample. We've got the vote() view going on.
> >
> > choice.votes += 1
> > choice.save()
> >
> > Suppose we've got thread1 and thread2 going on (high-load website):
> >
> > choice.votes is originally 16
> >
> > thread1.choice.votes += 1
> > thread2.choice.votes += 1
> > thread1.choice.save()
> > thread2.choice.save()
> >
> > choice.votes _should_ be 18 now, but is it 18 or 17?
>
> You're right to point this out -- it'll probably be 17. That
> particular example is a bad example; it'd be better to do "UPDATE
> choices SET votes=votes+1 WHERE id=X", which would always increment
> rather than setting the value directly.

So the best practices workaround would be to write raw SQL instead?

Hm. I can do that. I was already planning on swapping the templating
engine for Kid. I like how Django's really loosely coupled :)


Elver

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



i18n

2006-05-16 Thread Elver Loho

Is there a way to chain languages in the i18n interface?

We're using a custom Interchange tag right now to do i18n in our
webstore. We support Estonian, Latvian, Lithuanian, Russian, and
English. The language chaining goes something like this:

if locale is estonian:
  print i18n(message, estonian)
  if that is empty:
print message

if locale is english:
  print i18n(message, english)
  if that is empty:
print message

if locale is lithuanian:  # same for latvian
  print i18n(message, lithuanian)
  if that is empty:
print i18n(message, russian)
if that is empty:
  print i18n(message, english)
  if that is empty:
print message

For all others, we default to English.

Is there a way to do such complex translation chaining (lithuanian ->
russian -> english -> message) with Django's gettext?


Elver

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



Transactions and model.save()

2006-05-16 Thread Elver Loho

Hiya!

Someone raised this question in the comments of the 4th tutorial and
it's been bugging me to no end.

Let's take the poll sample. We've got the vote() view going on.

choice.votes += 1
choice.save()

Suppose we've got thread1 and thread2 going on (high-load website):

choice.votes is originally 16

thread1.choice.votes += 1
thread2.choice.votes += 1
thread1.choice.save()
thread2.choice.save()

choice.votes _should_ be 18 now, but is it 18 or 17?

Someone in #django mentioned that it'll work correctly when using
PostgreSQL, but probably not when using MySQL.

Our production system and my development system both use MySQL right
now. PostgreSQL is an option, but I'd rather not deploy that right
now.

But, anyhow, isn't the point of using database-agnostic middleware
like this that it'll work the same no matter what database you end up
using?

Anyhow, I'm just shopping for a framework right now. Django seems very
very nice, but there's something about it that keeps nagging me.
That's one such source of nag for me.

I did some searching of the mailing list archive earlier, but I
couldn't find this question answered. Or maybe I'm just too sleepy.


Elver

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