Yet another database question, please

[nmp]

Hello to all. I am only just learning both Python and PyGTK (with Glade).
I also need to learn how to use databases in my programs. My preliminary
research leads me in the direction of SQLAlchemy, which seems to be what
everybody else is using.

So, does anyone have a good example that shows how to tie these things
toegether? I would like to have the GUI dialogs and treeviews directly
interacting with the underlying tables and/or views.

[cough]Like Borland Delphi 1.0, in the nineties...[/cough]

Another question: I found that in Ubuntu, I was able to install the Glade
widgets for libgnomedb (libgnomedb3-glade3). Would these be usable with
Python/PyGTK, too? As is too common, the documentation provided is
somewhat scarce.

Any sort of pointers or suggestions welcome, of course.

 

[Bruno Desthuilliers]

nmp a écrit :

Hello to all. I am only just learning both Python and PyGTK (with Glade).
I also need to learn how to use databases in my programs. My preliminary
research leads me in the direction of SQLAlchemy, which seems to be what
everybody else is using.

Since it's not quite clear from your question: SQLAlchemy is a pretty
good package, but you need still need to know SQL to use it effectively
(if it's your case, please forget this remark).

So, does anyone have a good example that shows how to tie these things
toegether? I would like to have the GUI dialogs and treeviews directly
interacting with the underlying tables and/or views.

[cough]Like Borland Delphi 1.0, in the nineties...[/cough]

From experience (with Delphi, VB and a couple related but less known
systems), directly tying widgets to database is a pretty brittle
architecture for anything else than Q&D Simple Stupid GUI/DB pipelines.

 

[kyosohma]

Hello to all. I am only just learning both Python and PyGTK (with Glade).
I also need to learn how to use databases in my programs. My preliminary
research leads me in the direction of SQLAlchemy, which seems to be what
everybody else is using.

So, does anyone have a good example that shows how to tie these things
toegether? I would like to have the GUI dialogs and treeviews directly
interacting with the underlying tables and/or views.

[cough]Like Borland Delphi 1.0, in the nineties...[/cough]

Another question: I found that in Ubuntu, I was able to install the Glade
widgets for libgnomedb (libgnomedb3-glade3). Would these be usable with
Python/PyGTK, too? As is too common, the documentation provided is
somewhat scarce.

Any sort of pointers or suggestions welcome, of course.

You should try Dabo. It sounds like what you want to do and what Dabo
does dovetails nicely.

http://dabodev.com/

Mike

 

[nmp]

nmp a écrit :


Since it's not quite clear from your question: SQLAlchemy is a pretty
good package, but you need still need to know SQL to use it effectively
(if it's your case, please forget this remark).

I will forget the remark then

You didn't know that, but I have used SQL and designed/used relational
databases regularly since about 20 years ago. I just never programmed any
GUI programs for them, especially not in Python/PyGTK.

So, does anyone have a good example that shows how to tie these things
toegether? I would like to have the GUI dialogs and treeviews directly
interacting with the underlying tables and/or views.

[cough]Like Borland Delphi 1.0, in the nineties...[/cough]

From experience (with Delphi, VB and a couple related but less known
systems), directly tying widgets to database is a pretty brittle
architecture for anything else than Q&D Simple Stupid GUI/DB pipelines.

Well, that's one of the reasons I mentioned Delphi within a cough... I
remember using that some years ago for precisely the quick and dirty
hacks that you speak of. I am sure there are better ways, but can you
please point me to them? I am beginning to become a bit frustrated with
scraping all kinds of half-finished documentation together.

Perhaps a bit of background is in order: I would eventually like to be
able to create business applications for which I alreday have a few
ideas. Think accounting, inventory and such. For one of these programs I
would like to build, I have a schema of about 30 tables and views.

Of course I would like a very robust solution, this is very important.
However, fast and relatively "easy" development and prototyping are
important too. Python was "sold" to me as a language that is very
ceonvenient for this. I am beginning to see that, too. I really like the
language so far. I built a little GTK webbrowser with embedded Mozilla,
took stuff from different tutorials and put them together myself, this is
the sort of exercises I do to learn programming.

Accessing databases seems to be a bigger step though. There doesn't seem
to be a standardised way to do it. And I am slightly nervous about having
to reinvent any wheels.

I would not mind using code generators either, as long as they produce
very clean code that I can actually edit.

 

[nmp]

You should try Dabo.

I certainly will. It looks like a nice tool for its purpose.

It sounds like what you want to do

Perhaps I am mistaken but I doubt that it will ultimately be flexible
enough for the kind of programs I want to create.

But I am not there yet, obviously.

(it also does not show me how to do it with PyGTK)

and what Dabo does dovetails nicely.

Dovetails?

Sorry, English is not my native language

 

[Peter Decker]

Hello to all. I am only just learning both Python and PyGTK (with Glade).
I also need to learn how to use databases in my programs. My preliminary
research leads me in the direction of SQLAlchemy, which seems to be what
everybody else is using.

So, does anyone have a good example that shows how to tie these things
toegether? I would like to have the GUI dialogs and treeviews directly
interacting with the underlying tables and/or views.

[cough]Like Borland Delphi 1.0, in the nineties...[/cough]

Another question: I found that in Ubuntu, I was able to install the Glade
widgets for libgnomedb (libgnomedb3-glade3). Would these be usable with
Python/PyGTK, too? As is too common, the documentation provided is
somewhat scarce.

Any sort of pointers or suggestions welcome, of course.

You should try Dabo. It sounds like what you want to do and what Dabo
does dovetails nicely.

http://dabodev.com/

Dabo doesn't work with PyGTK, so if he goes with Dabo, he'll have to
settle for a GUI toolkit that looks native on all platforms instead of
just Gnome. ;-)

 

[Bruno Desthuilliers]

nmp a écrit :

I will forget the remark then

Sorry, was not obvious from your question !-)

(snip)

So, does anyone have a good example that shows how to tie these things
toegether? I would like to have the GUI dialogs and treeviews directly
interacting with the underlying tables and/or views.

[cough]Like Borland Delphi 1.0, in the nineties...[/cough]

From experience (with Delphi, VB and a couple related but less known
systems), directly tying widgets to database is a pretty brittle
architecture for anything else than Q&D Simple Stupid GUI/DB pipelines.

Well, that's one of the reasons I mentioned Delphi within a cough... I
remember using that some years ago for precisely the quick and dirty
hacks that you speak of. I am sure there are better ways, but can you
please point me to them?

Well... I'm afraid I never done any serious rich-client programming in
Python - I'm mostly doing web and sysadmin related stuff nowadays (that
is, for the or more past years). I just know that when I was doing
rich-client business apps on Window (that is: in a former life...), I
always ended up removing all those pesky "db-widgets" and manually
writing the code to tie GUI and model together - I guess that's what is
called a "controler" in the MVC triad ?-)

(snip)

Of course I would like a very robust solution, this is very important.
However, fast and relatively "easy" development and prototyping are
important too. Python was "sold" to me as a language that is very
ceonvenient for this.

Yeps, that's how they got me hooked too !-)

(snip)

Accessing databases seems to be a bigger step though. There doesn't seem
to be a standardised way to do it. And I am slightly nervous about having
to reinvent any wheels.

About DB access, there are two major APIs : the official (low-level -
that is,relatively to the other one...) db-api, and the higher-level
SQLAlchemy package. Note that while having an ORM part, SQLAlchemy is
first an higher-level SQL/Python integration layer, so you can still
think "relational" - but with something much more powerful than strings
to build your queries.

Tying the model (wether relational or not) with the UI is quite a
different problem. I assume you know what MVC mean, and from then I'm
afraid I can't help more.

 

[nmp]

Bruno Desthuilliers wrote:

[..]

About DB access, there are two major APIs : the official (low-level -
that is,relatively to the other one...) db-api, and the higher-level
SQLAlchemy package. Note that while having an ORM part, SQLAlchemy is
first an higher-level SQL/Python integration layer, so you can still
think "relational" - but with something much more powerful than strings
to build your queries.

Tying the model (wether relational or not) with the UI is quite a
different problem. I assume you know what MVC mean, and from then I'm
afraid I can't help more.

MVC is one of those vague abbreviations that describe the architecture of
three-tier client/server applications, right?

Anyway, I think I have found some study material. I don't know whether
these are really good examples, but I will be studying the source code of
<http://bauble.belizebotanic.org/> and <http://griffith.berlios.de/>.
These seem to be two programs in the same style that I want to create,
using both SQLAlchemy and PyGTK.

I have also found <https://storm.canonical.com/> (looks trustworthy) and
<http://projects.amor.org/geniusql> (website offline at the moment?)
which could be alternatives for SQLAlchemy. I am not sure at this point
if I want to go that course.

 

[Tim Chase]

and what Dabo does dovetails nicely.

Dovetails?

Sorry, English is not my native language

A carpentry term where two pieces of wood are formed to fit
together to create the joint:

http://images.google.com/images?q=dovetail

Used metaphorically to mean "as if they were meant to fit together".

(I would have replied off-list, as it's not really apropos, but
your email address was bogus)

-tkc

 

[Bruno Desthuilliers]

nmp a écrit :

Bruno Desthuilliers wrote:

[..]

About DB access, there are two major APIs : the official (low-level -
that is,relatively to the other one...) db-api, and the higher-level
SQLAlchemy package. Note that while having an ORM part, SQLAlchemy is
first an higher-level SQL/Python integration layer, so you can still
think "relational" - but with something much more powerful than strings
to build your queries.

Tying the model (wether relational or not) with the UI is quite a
different problem. I assume you know what MVC mean, and from then I'm
afraid I can't help more.

MVC is one of those vague abbreviations that describe the architecture of
three-tier client/server applications, right?

Nope. It's one of those vague abbreviations that describes the
architecture of GUI applications !-)

More seriously, the original MVC concept (which comes from Smalltalk) is
still worth studying.

Anyway, I think I have found some study material. I don't know whether
these are really good examples, but I will be studying the source code of
<http://bauble.belizebotanic.org/> and <http://griffith.berlios.de/>.
These seem to be two programs in the same style that I want to create,
using both SQLAlchemy and PyGTK.

I have also found <https://storm.canonical.com/> (looks trustworthy) and
<http://projects.amor.org/geniusql> (website offline at the moment?)
which could be alternatives for SQLAlchemy. I am not sure at this point
if I want to go that course.

Well, having used SQLAlchemy, I can tell you it's really worth it's
weight in gold.

 

[nmp]

nmp a écrit :

Bruno Desthuilliers wrote:

[..]

About DB access, there are two major APIs : the official (low-level -
that is,relatively to the other one...) db-api, and the higher-level
SQLAlchemy package. Note that while having an ORM part, SQLAlchemy is
first an higher-level SQL/Python integration layer, so you can still
think "relational" - but with something much more powerful than
strings to build your queries.

Tying the model (wether relational or not) with the UI is quite a
different problem. I assume you know what MVC mean, and from then I'm
afraid I can't help more.

MVC is one of those vague abbreviations that describe the architecture
of three-tier client/server applications, right?

Nope. It's one of those vague abbreviations that describes the
architecture of GUI applications !-)

More seriously, the original MVC concept (which comes from Smalltalk) is
still worth studying.

Well, if I find I need to, I will. I promise

Well, having used SQLAlchemy, I can tell you it's really worth it's
weight in gold.

Thank you. This was my impression too. So I will stick with it for now.

 

[nmp]

A carpentry term where two pieces of wood are formed to fit together to
create the joint:

http://images.google.com/images?q=dovetail

Used metaphorically to mean "as if they were meant to fit together".

Thank you.

(I would have replied off-list, as it's not really apropos, but your
email address was bogus)

I am a newsgroup user (comp.lang.python). Using invalid e-mail adresses
is common on Usenet nowadays. You know: privacy, spam, etc.