headers
Stef Telford | 1 Feb 21:49

RFP: SQLObject-Web ?


Hello Everyone,
    Okay.. I have a question. I think (perhaps wrongly but) that most
people are using SQLObject in a web fashion these days. To my limited
sight, the code seems structured to exist in a more non-web fashion.
What do I mean by this ?

    *) There is writeLocks - surely not required since most frameworks
run the entire thread under a transaction anyway. Surely these are
therefore, at best, depreciated in a web environment and, at worst,
obsolete. It also makes pickle hard (obviously) cause I have to remove
them from the object before storing into memcache and then assign a
new one after a 'get' (of course, I have to do this with sqlmeta
-anyway-, but at least I can see the reason d'etre with that. very
handy and cool)

    *) cache built in at a fundamental level - most web people would
probably feel safer with memcache, currently I don't see anyway to
disable this other than by hacking the get method inside SQLObject to
not put items into it's cache (at least, that's the way I got memcache
to be used and the inbuilt cache never used). Yes, I -can- subclass
the object, but surely the base object should be 'light' and then a
new SQLObject with caching derives from that. This would mean anyone
could subclass from the base object and the FK/Join goodness without
being forced to use SQLObjects caching.

    *) no query caching - seems strange to have object caching but no
query caching, when query caching is generally where 'web' starts to
notice major slowness. I have created a simple queryCache using a
global inside the servlet/framework request to do this, and it seems
(Continue reading)

Permalink | Reply | 13 comments |
headers
Oleg Broytmann | 1 Feb 22:40
X-Face
Picon
Favicon

Re: RFP: SQLObject-Web ?

Hello!

   My company uses SQLObject solely for desktop applications.

On Sun, Feb 01, 2009 at 03:49:46PM -0500, Stef Telford wrote:
>     *) There is writeLocks - surely not required since most frameworks
> run the entire thread under a transaction anyway.

   I don't see how a web transaction is related to multithread-safe locks.
Whatever a web transaction is, there are a lot of different web frameworks,
and who guarantees it is thread-safe to touch shared variables?

>     *) cache built in at a fundamental level - most web people would
> probably feel safer with memcache, currently I don't see anyway to
> disable this

   Probably by writing a Cache class that doesn't cache.

>     *) no query caching

   What is a query in terms of an ORM? If 'document' is an SQLObject,
attribute access like 'document.title' is implemented using a SQL query.
How does query caching help?
   In any case - if query caching helps, SQLObject will benefit if somebody
commits a code, right?

>     *) connection pooling - I would have thought (again perhaps
> naively) that in a web environment, this should exist outside the ORM.

   It is easy to disable: connection._pool = None.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Stef Telford | 2 Feb 00:25

Re: RFP: SQLObject-Web ?


Hello Oleg,

Oleg Broytmann wrote:
> Hello!
>
> My company uses SQLObject solely for desktop applications.
>
Understandable, and this is pretty much how I was thinking SQLObject
was designed/targetted for. This makes perfect sense, but in a web
framework perhaps not as much. No offense meant ;)
> On Sun, Feb 01, 2009 at 03:49:46PM -0500, Stef Telford wrote:
>> *) There is writeLocks - surely not required since most
>> frameworks run the entire thread under a transaction anyway.
>
> I don't see how a web transaction is related to multithread-safe
> locks. Whatever a web transaction is, there are a lot of different
> web frameworks, and who guarantees it is thread-safe to touch
> shared variables?
>
well, from what I have seen over the years, most web frameworks that
use an ORM do the following;
    start request handling in a thread
        create connection to db
        do processing
        commit connection/rollback capture
    end request

I know that's -very- high level, but, there is never really any
contention in such an environment and, therefore, there is no need for
(Continue reading)

Permalink | Reply | 11 comments |
headers
David Turner | 2 Feb 00:56
Favicon
Gravatar

Re: RFP: SQLObject-Web ?


On Sun, 2009-02-01 at 18:25 -0500, Stef Telford wrote:
> Hello Oleg,
> 
> Oleg Broytmann wrote:
> > Hello!
> >
> > My company uses SQLObject solely for desktop applications.
> >
> Understandable, and this is pretty much how I was thinking SQLObject
> was designed/targetted for. This makes perfect sense, but in a web
> framework perhaps not as much. No offense meant ;)
> > On Sun, Feb 01, 2009 at 03:49:46PM -0500, Stef Telford wrote:
> >> *) There is writeLocks - surely not required since most
> >> frameworks run the entire thread under a transaction anyway.
> >
> > I don't see how a web transaction is related to multithread-safe
> > locks. Whatever a web transaction is, there are a lot of different
> > web frameworks, and who guarantees it is thread-safe to touch
> > shared variables?
> >
> well, from what I have seen over the years, most web frameworks that
> use an ORM do the following;
>     start request handling in a thread
>         create connection to db
>         do processing
>         commit connection/rollback capture
>     end request
> 
> I know that's -very- high level, but, there is never really any
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oleg Broytmann | 2 Feb 12:38
X-Face
Picon
Favicon

Re: RFP: SQLObject-Web ?

On Sun, Feb 01, 2009 at 06:25:07PM -0500, Stef Telford wrote:
> Oleg Broytmann wrote:
> > My company uses SQLObject solely for desktop applications.
> >
> Understandable, and this is pretty much how I was thinking SQLObject
> was designed/targetted for. This makes perfect sense, but in a web

   I don't think it is how and what it's designed for. Its original author,
Ian Bicking, AFAIK, had been working in a web environment.

> framework perhaps not as much. No offense meant ;)

   No offence taken. :)

> >> *) There is writeLocks - surely not required since most
> >> frameworks run the entire thread under a transaction anyway.
> >
> > I don't see how a web transaction is related to multithread-safe
> > locks. Whatever a web transaction is, there are a lot of different
> > web frameworks, and who guarantees it is thread-safe to touch
> > shared variables?
> >
> well, from what I have seen over the years, most web frameworks that
> use an ORM do the following;
>     start request handling in a thread
>         create connection to db
>         do processing
>         commit connection/rollback capture
>     end request
>
(Continue reading)

Permalink | Reply | 9 comments |
headers
Iwan Vosloo | 2 Feb 14:22
Favicon

Tricky select with computed value

Hi there,

We have a class similar to this definition:

class Article(SQLObject):
  publishedDate = DateTimeCol()
  runningTime = IntCol()   # This is the number of days the article 
                           #  runs after being published

To now query for Articles that are still within their running time, you
can do something like this (assuming Postgresql):

Article.select("(age(article.published_date)) < (article.running_time *
'1 day'::interval)")

Not very pretty, and in our real app, we cannot do this anyways for
unrelated reasons. 

Is there a way to express this in Python instead?

Or how else could one do it? (I wondered if you can add a computed
attribute on the class, and somehow have SQLBuilder understand that...
but I imagine that's not possible.)

In the above, age is actually a postgresql function, so that part you
can write using the "q magic" in python.  But the multiplication (and
the typecast) on the other end is problematic to write in Python.

-i
(Continue reading)

Permalink | Reply | 2 comments |
headers
Oleg Broytmann | 2 Feb 15:12
X-Face
Picon
Favicon

Re: Tricky select with computed value

On Mon, Feb 02, 2009 at 03:22:05PM +0200, Iwan Vosloo wrote:
> Article.select("(age(article.published_date)) < (article.running_time *
> '1 day'::interval)")

   Try

from sqlobject.sqlbuilder import func, SQLConstant
Article.select(func.age(Article.q.publishedDate) < Article.q.runningTime * SQLConst("'1 day'::interval"))

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:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
Permalink | Reply | 1 comment |
headers
Iwan Vosloo | 2 Feb 15:48
Favicon

Re: Tricky select with computed value


On Mon, 2009-02-02 at 17:12 +0300, Oleg Broytmann wrote:
> On Mon, Feb 02, 2009 at 03:22:05PM +0200, Iwan Vosloo wrote:
> > Article.select("(age(article.published_date)) < (article.running_time *
> > '1 day'::interval)")
> 
>    Try
> 
> from sqlobject.sqlbuilder import func, SQLConstant
> Article.select(func.age(Article.q.publishedDate) < Article.q.runningTime * SQLConst("'1 day'::interval"))

Great, thanks Oleg, that works.

-i

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
Permalink | Reply | 0 comments |
headers
Stef Telford | 2 Feb 18:38

Re: RFP: SQLObject-Web ?


Oleg Broytmann wrote:
> On Sun, Feb 01, 2009 at 06:25:07PM -0500, Stef Telford wrote:
>> Oleg Broytmann wrote:
>>> My company uses SQLObject solely for desktop applications.
>>>
>> Understandable, and this is pretty much how I was thinking
>> SQLObject was designed/targetted for. This makes perfect sense,
>> but in a web
>
> I don't think it is how and what it's designed for. Its original
> author, Ian Bicking, AFAIK, had been working in a web environment.
>
>> framework perhaps not as much. No offense meant ;)
>
> No offence taken. :)
>

good show. I always get worried about people taking offense over
e-mail. I find that tone is very hard to convey.

>>>> *) There is writeLocks - surely not required since most
>>>> frameworks run the entire thread under a transaction anyway.
>>> I don't see how a web transaction is related to
>>> multithread-safe locks. Whatever a web transaction is, there
>>> are a lot of different web frameworks, and who guarantees it is
>>> thread-safe to touch shared variables?
>>>
>> well, from what I have seen over the years, most web frameworks
>> that use an ORM do the following; start request handling in a
(Continue reading)

Permalink | Reply | 8 comments |
headers
Oleg Broytmann | 2 Feb 20:42
X-Face
Picon
Favicon

Re: RFP: SQLObject-Web ?

On Mon, Feb 02, 2009 at 12:38:45PM -0500, Stef Telford wrote:
> Oleg Broytmann wrote:
> > On Sun, Feb 01, 2009 at 06:25:07PM -0500, Stef Telford wrote:
> > No offence taken. :)
> 
> good show. I always get worried about people taking offense over
> e-mail. I find that tone is very hard to convey.

   I know. I did it many time in this mailing list - inadvertently offended
people. Different levels of English knowledge, different vocabularies,
different understanding...

> > Still I don't understand. What do you mean by saying "there is no
> > contention"? If there are threads and there are shared variables -
> > the variables must be protected, right? Have I missed something?
> > There are global counters, e.g. in Alias - how would they fare if
> > different threads would want to increase them?
> 
> Well, at the start of every request, a connection is created to the
> database. Now, -any- rdbms worth it's salt basically creates an
> isolation level so that I can see -my- changes but no one else's
> changes

   Aha, I see. We are talking about different concepts. You are talking
about database isolation. I am talking about python shared variables. Those
locks in the code protect python variables, not database! Think about that
very pool, connection._pool - nobody (i.e., no other thread) should read it
even less should write to it until SQLObject finishes manipulating it. The
same is true for alias lock.
(Continue reading)

Permalink | Reply | 7 comments |

Gmane