chris | 6 May 20:35

Why must SQLObject expose database connections to users's?

Why does my TurboGears/SQLObject app need an explicit connection to database to
be exposed?

I'm thinking of the following line which *MUST* appear....

__connection__ = turbogears.database.PackageHub("myapp")

Isn't a goal for ORMs to hide all this database connection stuff?

Chris

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Oleg Broytmann | 6 May 20:53
X-Face

Re: Why must SQLObject expose database connections to users?

On Tue, May 06, 2008 at 11:37:55AM -0700, chris <at> seberino.org wrote:
> Why does my TurboGears/SQLObject app need an explicit connection to database to
> be exposed?

   This is like asking why there are constructors in OO programming. The
answer for both questions is - because you need to initialize the thing.

> Isn't a goal for ORMs to hide all this database connection stuff?

   Yes, but remember these things:

1. The Law of Leaky Abstractions - it is very hard to completely hide the
underlying level.
2. There is no way for an ORM to guess where you do want to connect to.
3. What if one would want to connect to two different databases? Should the
ORM to guess both connections? How?!

Oleg.
--

-- 
     Oleg Broytmann            http://phd.pp.ru/            phd <at> phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
chris | 6 May 21:19

Re: Why must SQLObject expose database connections to users?

Oleg

Thank you.  See reponses below.

On Tue, May 06, 2008 at 10:53:29PM +0400, Oleg Broytmann wrote:
> > Isn't a goal for ORMs to hide all this database connection stuff?
>
>    Yes, but remember these things:
>
> 1. The Law of Leaky Abstractions - it is very hard to completely hide the
> underlying level.
> 2. There is no way for an ORM to guess where you do want to connect to.
> 3. What if one would want to connect to two different databases? Should the
> ORM to guess both connections? How?!

Yes but couldn't this be done in a config file rather than in Python code?
Unless I'm missing something,
this is *already* done in TurboGears/SQLObject as the config
file there defines a sqlobject.dburi variable!

Chris

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Oleg Broytmann | 6 May 21:48
X-Face

Re: Why must SQLObject expose database connections to users?

On Tue, May 06, 2008 at 12:19:05PM -0700, chris <at> seberino.org wrote:
> On Tue, May 06, 2008 at 10:53:29PM +0400, Oleg Broytmann wrote:
> > > Isn't a goal for ORMs to hide all this database connection stuff?
> > 2. There is no way for an ORM to guess where you do want to connect to.
> 
> Yes but couldn't this be done in a config file rather than in Python code?

   SQLObject is a library, not a framework that dictates the format and the
location of its config file(s).

> Unless I'm missing something,
> this is *already* done in TurboGears/SQLObject as the config
> file there defines a sqlobject.dburi variable!

   Don't know anything about TurboGears. SQLObject is a separate project,
not a subproject of TG.

On Tue, May 06, 2008 at 11:53:31AM -0700, chris <at> seberino.org wrote:
> In my TurboGears/SQLObject app, I manually commit changes to the database
> with a line like the following...
> 
> MyObject._connection.commit()

   Ah, that is what you meant by saying "explicit connection". I see now.

> It works but looks ugly since _connection is "private variable" that should not
> be accessed right?

   Yes, to a degree. On the other hand, .commit() really belongs to the
connection. After a program has manipulated a hundred of SQLObjects it has
(Continue reading)

chris | 6 May 21:59

Re: Why must SQLObject expose database connections to users?

On Tue, May 06, 2008 at 11:48:16PM +0400, Oleg Broytmann wrote:
>    I usually keep a reference to the connection, so I don't need to extract
> it from SQLObjects:
>
> connection = ...
>
> class MyTable(SQLObject):
>    _connection = connection
>
> connection.commit()

Hmm. There seems to be 2 ways to do commits.  You can commit from
MyTable._connection.commit() or

__connection__ = turbogears.database.PackageHub("blueduck")

If I'm not mistaken, the former only commits the current transaction while
the latter commits *ALL* tranactions?

(Someone convinced me to use the former so I switched.)

Chris

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Jorge Vargas | 6 May 23:01

Re: Why must SQLObject expose database connections to users's?

On Tue, May 6, 2008 at 2:37 PM,  <chris <at> seberino.org> wrote:
> Why does my TurboGears/SQLObject app need an explicit connection to database to
>  be exposed?
>
>  I'm thinking of the following line which *MUST* appear....
>
>  __connection__ = turbogears.database.PackageHub("myapp")
>
>  Isn't a goal for ORMs to hide all this database connection stuff?
no the goal of ORM is to provide an Object frontend to the Relational
backend. This request is unacceptable. you may need different
connections to different dbs. the abstraction is already a lot did you
read the PackageHub code?

Please don't try to make the tool fit your needs and ignore everyone
else's. This discussion already ended in the TG list.
>
>  Chris
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  sqlobject-discuss mailing list
>  sqlobject-discuss <at> lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

(Continue reading)

chris | 6 May 23:42

Re: Why must SQLObject expose database connections to users's?

On Tue, May 06, 2008 at 05:01:28PM -0400, Jorge Vargas wrote:
> On Tue, May 6, 2008 at 2:37 PM,  <chris <at> seberino.org> wrote:
> > Why does my TurboGears/SQLObject app need an explicit connection to database to
> >  be exposed?
> >
> >  I'm thinking of the following line which *MUST* appear....
> >
> >  __connection__ = turbogears.database.PackageHub("myapp")
> >
> >  Isn't a goal for ORMs to hide all this database connection stuff?
> no the goal of ORM is to provide an Object frontend to the Relational
> backend. This request is unacceptable. you may need different
> connections to different dbs. the abstraction is already a lot did you
> read the PackageHub code?

SQLObject is awesome.  Yes the level of abstraction is all anyone could ask
for.  Everyone in the TurboGears/SQLObject community is so talented I knew I'd
learn something from asking a possibly dumb question.  My apologies if I
annoyed anyone.

Chris

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Gmane