> It'd be nice to have this in a database independent format - to make it
> easy to change the database you're using.
I didn't think about this before, but you are right.
In the end, users may want to backup the django application and not the
(postgres) database, which speaks for the
On 12/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Personally, I think class attributes are fine.
Also given how Django describes the schema and from there builds the
database as opposed to RoR which wants you to design the database up
front, I think the names of the Django functions like
Milton Waddams wrote:
> Can someone tell me why this doesn't work?
>
> {% ifequal forloop.counter0 1 %}
>
> there are enough loops and the output of {{forloop.counter0}} does
> print 1 at the appropriate place?
>
> By work I mean it is never equal, I've tried putting the 1 in quotes
> with no
Can someone tell me why this doesn't work?
{% ifequal forloop.counter0 1 %}
there are enough loops and the output of {{forloop.counter0}} does
print 1 at the appropriate place?
By work I mean it is never equal, I've tried putting the 1 in quotes
with no difference.
Andreas Neumeier wrote:
like executing pg_dump from the view? I thought about that, but I did
not want to execute something external.
I was more thinking of get_list(...) or something similare, but that
would propably break relations on restoring?
so pg_dump would be the most consistent
A symbol which is a unique string is not the story here, it turns out
-- dynamic language is!
has_many :milestones
is apparently a call which generates code inside of the class! Can it
be replicated in python for ORM purposes?
On 12/14/05, Andreas Neumeier <[EMAIL PROTECTED]> wrote:
> I was wondering, if it is possible to do a entire backup of the
> database into a, let's say XML file or something.
>
> The intention is to offer a easy possibility to users to install
> applications and roll back to previor states, like
You might try the mod_python list...
¿What does the apache error log say?
El vie, 02-12-2005 a las 21:56 -0800, [EMAIL PROTECTED]
escribió:
> I hava Windows, apache 2.0.55 python 2.4.2 and mod python 3.2.5b
> installed.
>
> I have add to httpd.conf LoadModule for mod_pythone.
>
> But apache
On 12/14/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> True. SQL was designed and has continued development for the sole
> purpose of data manipulation. Why then replace SQL with Python to
> describe this data structure.
For me, it's a question of portability; even though SQL is a
True. SQL was designed and has continued development for the sole
purpose of data manipulation. Why then replace SQL with Python to
describe this data structure.
like executing pg_dump from the view? I thought about that, but I did
not want to execute something external.
I was more thinking of get_list(...) or something similare, but that
would propably break relations on restoring?
so pg_dump would be the most consistent solution, tho.
--
Andreas
Hi there,
I was wondering, if it is possible to do a entire backup of the
database into a, let's say XML file or something.
The intention is to offer a easy possibility to users to install
applications and roll back to previor states, like having a
backup/restore button on the admin interface.
I'd prefer to see a two stage approach to contributing applications to
Django where newly contributed apps are in some sub-directory like
django.extras instead of django.contrib that contains more
standardized and popular applications like admin.
I'm thinking of KDE as a model with there
On 12/14/05, Flavio Curella <[EMAIL PROTECTED]> wrote:
> I think class django.contrib.syndication.feeds.Feed need
> item_categories methods that allow use of categories also in high-level
> syndication framework.
A few days back, I posted a slightly different suggestion as a ticket:
Wilson Miner wrote:
I haven't got around to posting those with guidelines, but I've
attached a version you migth be able to use.
Thanks, I'll keep it!
I think class django.contrib.syndication.feeds.Feed need
item_categories methods that allow use of categories also in high-level
syndication framework.
Something like this should work:
# ITEM CATEGORIES --One of the following three is optional. The
# framework looks for them in this
I haven't got around to posting those with guidelines, but I've attached a version you migth be able to use.Cheers,WilsonOn 12/3/05, Maniac
<[EMAIL PROTECTED]> wrote:
I'm writing a blog post about Django and want to use a logo as adecoration. There are number of nice badges
Robert Hicks wrote:
I am not sure what you are saying here. Since SQLObject is under the
LGPL, your application can be under anything you want it to be. There
is no ambiguity.
Right... the only exception is that if you make changes to SQLObject
itself. The cool thing
about the LGPL is
I am not sure what you are saying here. Since SQLObject is under the
LGPL, your application can be under anything you want it to be. There
is no ambiguity.
Robert
braver wrote:
> Now that my appetite is whetted by the cris-py fresh Object-Relational
> Managers, I keep collecting and comparing them. So far I've found that
> ruby's ActiveRecord is separable from RoR, and I found SQLobject.org, a
> totally pythonic ORM (but no cigar... i.e., web). So it
On 12/14/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> True a GUI can't totally replace hand coded SQL. However, it certainly
> speeds a lot of the process up. Fine tuning can be done afterwards.
Guess that is a very subjective measurement. Working out the model in
Django's models/
True a GUI can't totally replace hand coded SQL. However, it certainly
speeds a lot of the process up. Fine tuning can be done afterwards.
On 14 Dec 2005, at 12:04, [EMAIL PROTECTED] wrote:
Its another surplus layer which complicates the process.
That's one way to look at it, but the other is that the Django model
contains more information than an SQL create statement. It
centralises all information about the layout and
Kenneth Gonsalves wrote:
On Wednesday 14 Dec 2005 5:34 pm, [EMAIL PROTECTED] wrote:
native method (SQL). I'd much rather build my database up using
a nice GUI then get Rails to 'plug' into it. Instead with Django
you have to code a database structure in Python which Django then
produces
On Wednesday 14 Dec 2005 5:34 pm, [EMAIL PROTECTED] wrote:
> native method (SQL). I'd much rather build my database up using
> a nice GUI then get Rails to 'plug' into it. Instead with Django
> you have to code a database structure in Python which Django then
> produces using SQL.
you can code
There's little difference then. In Django you write Python code to
represent your database. In RoR you produce the database first in its
native method (SQL). I'd much rather build my database up using a nice
GUI then get Rails to 'plug' into it. Instead with Django you have to
code a database
Yes, I think what perhaps missing / not appropriate is Not much
discussion / documentation of what is "The Django Way."
We will have to wait until 1.0 I guess.
27 matches
Mail list logo
