On Wednesday 21 Dec 2005 5:35 am, iGL wrote:
> I must have missed it in the doc. Would you like to give me the
> corresponding link?
look for 'legacy database' in the docs
--
regards
kg
http://www.livejournal.com/users/lawgon
tally ho! http://avsap.org.in
ಇಂಡ್ಲಿನಕ್ಸ வாழ்க!
I must have missed it in the doc. Would you like to give me the
corresponding link?
TIA,
Giorgi
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
braver wrote:
> I was reading
>
> http://www.loudthinking.com/arc/000545.html
>
> and it has an emphasis on Ruby's "beauty", and parsimony, as
> demonstrated by the code excerpt (David: "I was more surprised to learn
> that someone would actually prefer something like"):
>
> class Project(meta.
If anyone is interested in more on this very topic:
http://blog.ianbicking.org/more-on-python-metaprogramming.html
Same discussion as here.
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
Po
braver wrote:
> 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?
>
>
Not really. Read up on metaclasse
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?
Afternoon wrote:
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 abou
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
"standar
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.
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/ direc
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 con
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 u
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
On 12/13/05, braver <[EMAIL PROTECTED]> wrote:
>
> Um, I guess I wonder what it "means" in terms of syntactic sugar -- the
> semantics is clear, and that's the claimed ruby's hallmark. I don't
> yet have a handle on those "symbol" things like :poll ("they're like
> strings" --huh?), and what's be
Um, I guess I wonder what it "means" in terms of syntactic sugar -- the
semantics is clear, and that's the claimed ruby's hallmark. I don't
yet have a handle on those "symbol" things like :poll ("they're like
strings" --huh?), and what's belongs_to? I wonder what would be the
closest pythonic sy
On 12/13/05, braver <[EMAIL PROTECTED]> wrote:
> OK, can someone please explain to a pythonista what exactly does a
> phrase like
>
> has_many :milestones
>
> mean, and what in python prevents us from mimicking it more closely?
It's expressing a many-to-many or many-to-one relationship. For
examp
OK, can someone please explain to a pythonista what exactly does a
phrase like
has_many :milestones
mean, and what in python prevents us from mimicking it more closely?
On 12/13/05, braver <[EMAIL PROTECTED]> wrote:
> and it has an emphasis on Ruby's "beauty", and parsimony, as
> demonstrated by the code excerpt (David: "I was more surprised to learn
> that someone would actually prefer something like"):
Except David glosses over an awful lot in that example; be
Alexy,
although I am not Adrian, I still felt compelled to comment. :)
On 12/13/05, braver <[EMAIL PROTECTED]> wrote:
> class Project(meta.Model):
> project_manager = meta.ForeignKey(ProjectManager)
> milestones = meta.OneToOneField(Milestone)
> categories = meta.ManyToManyField(Category)
>
I was reading
http://www.loudthinking.com/arc/000545.html
and it has an emphasis on Ruby's "beauty", and parsimony, as
demonstrated by the code excerpt (David: "I was more surprised to learn
that someone would actually prefer something like"):
class Project(meta.Model):
project_manager = meta
23 matches
Mail list logo
