sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Indexed access to a SelectResults

[Ian B. <ia...@co...>]

On Wed, 2003-07-16 at 17:42, Matt Goodall wrote:
> > It would, though, create a bunch of SELECTs, like SELECT blah
> > LIMIT 1 OFFSET 0, SELECT blah LIMIT 1 OFFSET 1, etc.
> > 
> > The problem is the way you're using it.
> 
> Unfortunately, it's not my code - it's another package that is walking
> the list using an index. I can probably change that package but
> couldn't/shouldn't SQLObject be a bit more graceful under these
> circumstances?

I don't know.  If the code is going to treat select results as a list, a
list seems like a reasonable thing to use (i.e.,
list(Whatever.select())).  

You could, generically, have a proxy class that batches the fetches, and
caches the results temporarily (while it's waiting for your code to do
another loop).  There's no reason it has to have specific support for
SQLObject either.  Maybe such a thing already exists (probably does in
*someone's* code... maybe on the ASPN recipe site).

> To be honest, it's really the multiple COUNT calls that bother me as it
> seems unnecessary. The multiple SELECT calls to retrieve the objects are
> to be expected but can possibly be avoided.

Yeah.  That is weird.  Ah... after some effort, I'm afraid I found why
it happens.  list() tries to get the length of the things it's
converting.  That's a pain in the but.  Maybe I'll post to
comp.lang.python about how to get around this.

> > all = list(Entity.select())
> > for i in range(len(all)):
> >     print all[i]
> 
> This is effectively how I am working around the "problem" for now, by
> passing a list() rather than a SelectResults.
> 
> > 
> > # or:
> > all = Entity.select()
> > for i, obj in enumerate(all):
> >     print obj
> 
> I'm not sure I see the benefit of this. Doesn't SQLObject already use a
> generator to walk the result of the query? Wouldn't this just wrap one
> generator in another?

That's how enumerate is supposed to work.  It's for when the underlying
code really wants to get an index along with the object.  If that code
you're using *doesn't* use that index, then that's just bad programming,
and it should iterate directly.

  Ian

Re: [SQLObject] subclassing style classes

[John A. B. <ja...@os...>]

Once again, this time with the patch. :)

-jab

--
John A. Barbuto				ja...@os...
Senior System Administrator,
Open Source Development Network		http://www.osdn.com/
      

Re: [SQLObject] subclassing style classes

[Ian B. <ia...@co...>]

On Wed, 2003-07-16 at 18:14, John A. Barbuto wrote:
> Hi,
> 
> I'm using SQLObject for a new project of mine, and despite a few issues,
> I'm liking it a lot better than the other alternatives I've tried.  
> 
> One problem I've noticed is regarding style classes.  I want to make my
> own subclass of MixedCaseUnderscoreStyle with a few tiny changes, but
> the utility functions the class uses (mixedToUnder, etc) aren't
> exported.  I could import them manually, but that seems inelegant, so I
> see two alternatives:
> 
> 1. add the functions to the __all__ variable.
> 2. create a MixIn class with these functions (now methods) that is
> inherited along with the Style class.
> 
> I attached a patch (against CVS) with does number 2.  I think it's a
> cleaner approach...thoughts?  Are style classes just not meant to be
> subclassed further?

Style classes are specifically meant to be subclassed further.  __all__
is there because it's nice to do from SQLObject import * without mucking
up the namespace too badly.  A utility function like mixedToUnder would
probably only be used once in your application, so you wouldn't want it
imported by default.  But it's fine to import it and use it otherwise
(though I guess I'm fuzzy in my use of _ to mark private functions
through SQLObject, though I'm also fuzzy on just what is private).

I think I had a mixin at one point, but didn't use it because mixins
seem conceptually heavy where a function would do.

  Ian

[SQLObject] subclassing style classes

[John A. B. <ja...@os...>]

Hi,

I'm using SQLObject for a new project of mine, and despite a few issues,
I'm liking it a lot better than the other alternatives I've tried. =20

One problem I've noticed is regarding style classes.  I want to make my
own subclass of MixedCaseUnderscoreStyle with a few tiny changes, but
the utility functions the class uses (mixedToUnder, etc) aren't
exported.  I could import them manually, but that seems inelegant, so I
see two alternatives:

1. add the functions to the __all__ variable.
2. create a MixIn class with these functions (now methods) that is
inherited along with the Style class.

I attached a patch (against CVS) with does number 2.  I think it's a
cleaner approach...thoughts?  Are style classes just not meant to be
subclassed further?

-jab

--=20
John A. Barbuto				ja...@os...
Senior System Administrator,
Open Source Development Network		http://www.osdn.com/
     =20

Re: [SQLObject] Indexed access to a SelectResults

[Matt G. <ma...@po...>]

On Wed, 2003-07-16 at 20:22, Ian Bicking wrote:
> On Wed, 2003-07-16 at 08:37, Matt Goodall wrote:
> > If you have code like this
> > 
> >     all = Entity.select('all')
> >     for i in range(len(all)):
> >        print all[i]
> > 
> > you get a whole stream of SQL calls. For a table with n rows you 
> > actually get 2n+1 SQL calls: 1 initial COUNT(*) and then a COUNT(*) and 
> > SELECT for each row.
> > 
> > It makes sense for a SelectResults objects to cache the COUNT result on 
> > the first len() so that future len() calls don't go back to the database?
> 
> Huh... I don't know why it's creating lots of COUNT calls.  Is it
> really?

Yes. It seems to be the last line of SelectResults.__getitem__ that is
causing this, not sure why at the moment otherwise I'd send a patch.

> It would, though, create a bunch of SELECTs, like SELECT blah
> LIMIT 1 OFFSET 0, SELECT blah LIMIT 1 OFFSET 1, etc.
> 
> The problem is the way you're using it.

Unfortunately, it's not my code - it's another package that is walking
the list using an index. I can probably change that package but
couldn't/shouldn't SQLObject be a bit more graceful under these
circumstances?

To be honest, it's really the multiple COUNT calls that bother me as it
seems unnecessary. The multiple SELECT calls to retrieve the objects are
to be expected but can possibly be avoided.

> You should iterate directly
> over the result, or force getting everything at once by doing list(all).
> Like either:
> 
> all = list(Entity.select())
> for i in range(len(all)):
>     print all[i]

This is effectively how I am working around the "problem" for now, by
passing a list() rather than a SelectResults.

> 
> # or:
> all = Entity.select()
> for i, obj in enumerate(all):
>     print obj

I'm not sure I see the benefit of this. Doesn't SQLObject already use a
generator to walk the result of the query? Wouldn't this just wrap one
generator in another?

Thanks, Matt

-- 
Matt Goodall, Pollenation Internet Ltd
w: http://www.pollenation.net
e: ma...@po...

Re: [SQLObject] Indexed access to a SelectResults

[Ian B. <ia...@co...>]

On Wed, 2003-07-16 at 08:37, Matt Goodall wrote:
> If you have code like this
> 
>     all = Entity.select('all')
>     for i in range(len(all)):
>        print all[i]
> 
> you get a whole stream of SQL calls. For a table with n rows you 
> actually get 2n+1 SQL calls: 1 initial COUNT(*) and then a COUNT(*) and 
> SELECT for each row.
> 
> It makes sense for a SelectResults objects to cache the COUNT result on 
> the first len() so that future len() calls don't go back to the database?

Huh... I don't know why it's creating lots of COUNT calls.  Is it
really?  It would, though, create a bunch of SELECTs, like SELECT blah
LIMIT 1 OFFSET 0, SELECT blah LIMIT 1 OFFSET 1, etc.

The problem is the way you're using it.  You should iterate directly
over the result, or force getting everything at once by doing list(all).
Like either:

all = list(Entity.select())
for i in range(len(all)):
    print all[i]

# or:
all = Entity.select()
for i, obj in enumerate(all):
    print obj

Of course, the second is better as you won't pull all the objects into
memory at once.  enumerate isn't defined in Python 2.2, so you can use:

from __future__ import generators

def enumerate(iterable):
    i = 0
    for obj in iterable:
        yield i, obj
        i += 1

[SQLObject] Indexed access to a SelectResults

[Matt G. <ma...@po...>]

If you have code like this

    all = Entity.select('all')
    for i in range(len(all)):
       print all[i]

you get a whole stream of SQL calls. For a table with n rows you 
actually get 2n+1 SQL calls: 1 initial COUNT(*) and then a COUNT(*) and 
SELECT for each row.

It makes sense for a SelectResults objects to cache the COUNT result on 
the first len() so that future len() calls don't go back to the database?

Another relatively easy way of improving performance in the above 
scenario would be if SelectResults read and cache blocks of objects, 10 
at a time for example, even if only one of those objects was actually 
returned to the caller.

Anyway, just some thoughts to help SQLObject "scale up" a bit. I have no 
idea whether these ideas would break other parts of SQLObject ;-).

Cheers, Matt

-- 
Matt Goodall, Pollenation Internet Ltd
w: http://www.pollenationinternet.com
e: ma...@po...

Re: [SQLObject] Zope 2/Python 2.1 support

[Sidnei da S. <si...@re...>]

| Ack... just thinking about that stuff makes my head hurt.  ZODB and
| acquisition together create this weird environment that always seems
| unpredictable to me.  I'd be quite happy avoiding those -- in fact,
| anything that allows me to avoid those would be a feature in my mind. 
| (Well, ZODB probably isn't so bad, but I still don't entirely understand
| how it fits into the entire system)
| 
| I would expect that SQLObject instances wouldn't live in ZODB, or in the
| Zope filesystem or anything like that.  For rendering and manipulation
| you'd use Python Scripts and templates and such, i.e., SQLObject
| instances would never be directly published.

Ok, thats pretty simple for you to do (maybe not entirely safe, but
that's another issue...) . For using it in Python Scripts you'll
probably have to make a security assertion that SQLObject classes are
importable. I would add one by one until it gets usable, because you
may not need all of them.

| > Good to know! Just for curiosity, what is the 'other python stuff'
| > you're interested in? Would it be Twisted?
| 
| Nah, I'm not a big fan of Twisted.  Nice guys, some good ideas, but I
| don't think asynchronous programming makes much sense past low-level
| stuff.  Just as an example, SQLObject would not work well with Twisted
| at all, since it hides blocking code (i.e., database calls), and you
| have to be very careful about such code when doing asynchronous
| programming.  Twisted is very different from Zope, but just as insular,
| which is a big drawback for me.
| 
| I've worked with Webware a fair amount, and I've now I'm hoping to help
| bring together all the similar alternatives, of which there are an
| excessive number.  And then there's the form processing library which is
| always on the back of my mind, but always feels a little way off for
| me...

Like, you want to write a standalone form processing library for using
with SQLObject? Or do you have a existing implementation in mind that
you want to adapt?

[]'s
-- 
Sidnei da Silva (dreamcatcher) <si...@re...>
Debian GNU/Linux  2.4.20-powerpc ppc

People are going to scream bloody murder about that.
	-- Seen on linux-kernel
-----------------------------------------------------------------------
Verified for virus by mail.redesul.com.br
Scanner: clamscan / ClamAV - Version 0.54 - Updated 08/07/2003

Re: [SQLObject] [patch] sqlRepr refactoring + goodies

[Sidnei da S. <si...@re...>]

On Mon, Jul 14, 2003 at 11:34:47PM -0500, Ian Bicking wrote:
| On Mon, 2003-07-14 at 22:42, Sidnei da Silva wrote:
| > Howdy,
| > 
| > I just refactored the sqlRepr method into a separate module called
| > Converters and made it a registry, so one can register a custom
| > converter for a type SQLObject doesnt knows about without modifying
| > code. Attached is the patch for adding this functionality, plus some
| > whitespace cleaning and a DateCol (I dont know exactly what is the
| > plan for Date/DateTime/Timestamp, but I would like to know so I can
| > implement something better).
| > 
| > Two questions:
| > 
| > Q1: how hard is it to get me CVS access, so I can contribute more
| > easily?
| 
| Yeah, that'd be fine, if you give me your SF username.  

dreamcatcher

| So long as you
| don't mind me editing your work or whatever.  

No problem!

| Or if you have something
| extensive or experimental you want to do, it should probably go in a
| branch.  

Yeah, be sure. After being boldy warned by Jim Fulton 2 or 3 times you
never *ever* will want to do experimental stuff out of a branch again.
Trust me :)

| > Q2: whats the policy on adding new functionality? what about tests?
| 
| Well, I don't always add tests when I add new functionality.  But I am
| always wrong when I don't.  Therefore everyone else definitely must add
| tests ;)
| 
| Of course, it depends.  DateCol certainly doesn't need a test.

Ok. I'll try to add some here and there as I go browsing the source then.

[]'s
-- 
Sidnei da Silva (dreamcatcher) <si...@re...>
Debian GNU/Linux  2.4.20-powerpc ppc

"If that makes any sense to you, you have a big problem."
		-- C. Durance, Computer Science 234
-----------------------------------------------------------------------
Verified for virus by mail.redesul.com.br
Scanner: clamscan / ClamAV - Version 0.54 - Updated 08/07/2003

Re: [SQLObject] [patch] sqlRepr refactoring + goodies

[Ian B. <ia...@co...>]

On Mon, 2003-07-14 at 22:42, Sidnei da Silva wrote:
> Howdy,
> 
> I just refactored the sqlRepr method into a separate module called
> Converters and made it a registry, so one can register a custom
> converter for a type SQLObject doesnt knows about without modifying
> code. Attached is the patch for adding this functionality, plus some
> whitespace cleaning and a DateCol (I dont know exactly what is the
> plan for Date/DateTime/Timestamp, but I would like to know so I can
> implement something better).
> 
> Two questions:
> 
> Q1: how hard is it to get me CVS access, so I can contribute more
> easily?

Yeah, that'd be fine, if you give me your SF username.  So long as you
don't mind me editing your work or whatever.  Or if you have something
extensive or experimental you want to do, it should probably go in a
branch.  

> Q2: whats the policy on adding new functionality? what about tests?

Well, I don't always add tests when I add new functionality.  But I am
always wrong when I don't.  Therefore everyone else definitely must add
tests ;)

Of course, it depends.  DateCol certainly doesn't need a test.

  Ian

Re: [SQLObject] Zope 2/Python 2.1 support

[Ian B. <ia...@co...>]

On Mon, 2003-07-14 at 22:58, Sidnei da Silva wrote:
> On Mon, Jul 14, 2003 at 10:43:54PM -0500, Ian Bicking wrote:
> | Do you think there is trouble outside of the Python 2.1 issue?  It'd be
> | a little annoying, but I'm okay with it -- when I compare it to writing
> | Z SQL methods, porting SQLObject to 2.1 seems quite enjoyable ;)
> 
> There are some stuff that would scare me. For example, getting a
> SQLObject Connection to play nicely with the Zope Transaction
> Machinery. Thats the tricky part. There is also a problem that its
> quite difficult to get Zope to display non-persistent objects (eg:
> stuff coming from SQLObject), and you can't mix new-style classes with
> ExtensionClass. If you just want to use SQLObject to do the same stuff
> as SQLScript, but in an easier way, you wont have much trouble, but if
> you want to have SQLObject to behave like content, then it will be
> quite hard, because you'll need some stuff to be persistent and some
> not. Or play acquisition tricks to get SQLObjects to behave like they
> are inside the ZODB.

Ack... just thinking about that stuff makes my head hurt.  ZODB and
acquisition together create this weird environment that always seems
unpredictable to me.  I'd be quite happy avoiding those -- in fact,
anything that allows me to avoid those would be a feature in my mind. 
(Well, ZODB probably isn't so bad, but I still don't entirely understand
how it fits into the entire system)

I would expect that SQLObject instances wouldn't live in ZODB, or in the
Zope filesystem or anything like that.  For rendering and manipulation
you'd use Python Scripts and templates and such, i.e., SQLObject
instances would never be directly published.

> | Before X3 I am probably going to be pushing them to use something other
> | than Zope, but that may or may not go anywhere.  In my non-professional
> | work (where Zope 3 would currently have to live) I'm more interested in
> | other Python web stuff besides Zope.  But I'd certainly support making
> | SQLObject and Zope 3 work together.
> 
> Good to know! Just for curiosity, what is the 'other python stuff'
> you're interested in? Would it be Twisted?

Nah, I'm not a big fan of Twisted.  Nice guys, some good ideas, but I
don't think asynchronous programming makes much sense past low-level
stuff.  Just as an example, SQLObject would not work well with Twisted
at all, since it hides blocking code (i.e., database calls), and you
have to be very careful about such code when doing asynchronous
programming.  Twisted is very different from Zope, but just as insular,
which is a big drawback for me.

I've worked with Webware a fair amount, and I've now I'm hoping to help
bring together all the similar alternatives, of which there are an
excessive number.  And then there's the form processing library which is
always on the back of my mind, but always feels a little way off for
me...

  Ian

Re: [SQLObject] Zope 2/Python 2.1 support

[Sidnei da S. <si...@re...>]

On Mon, Jul 14, 2003 at 10:43:54PM -0500, Ian Bicking wrote:
| Do you think there is trouble outside of the Python 2.1 issue?  It'd be
| a little annoying, but I'm okay with it -- when I compare it to writing
| Z SQL methods, porting SQLObject to 2.1 seems quite enjoyable ;)

There are some stuff that would scare me. For example, getting a
SQLObject Connection to play nicely with the Zope Transaction
Machinery. Thats the tricky part. There is also a problem that its
quite difficult to get Zope to display non-persistent objects (eg:
stuff coming from SQLObject), and you can't mix new-style classes with
ExtensionClass. If you just want to use SQLObject to do the same stuff
as SQLScript, but in an easier way, you wont have much trouble, but if
you want to have SQLObject to behave like content, then it will be
quite hard, because you'll need some stuff to be persistent and some
not. Or play acquisition tricks to get SQLObjects to behave like they
are inside the ZODB.

| 2.2 has been out for so very long that I don't know what to make of Zope
| not supporting it.
| 
| I don't know, I'm not entirely sold on the idea.  I'm just trying to
| make my Zope 2 development time more pleasant, because I'm not enjoying
| it very much.  It's all strictly procedural programming (no OO), and I
| feel like the way we're using the database has a lot to do with that. 
| So SQLObject seemed like a nice starting point.

Yes, it may be a nice start. You just need to figure out the easier
way to do it. 

| > BUT, if you want to go the Zope 3 route, I would love to give you a
| > hand >:)
| 
| Well, all my Zope work is strictly professional.  Certainly when X3
| comes around I'll be pushing strongly for the place I'm working for to
| use it for new projects, and I wouldn't even dismiss the possibility
| that Zope could convert me in the process, but I don't know that I want
| to wait for that.  

Let's hope this happens soon :)

| Before X3 I am probably going to be pushing them to use something other
| than Zope, but that may or may not go anywhere.  In my non-professional
| work (where Zope 3 would currently have to live) I'm more interested in
| other Python web stuff besides Zope.  But I'd certainly support making
| SQLObject and Zope 3 work together.

Good to know! Just for curiosity, what is the 'other python stuff'
you're interested in? Would it be Twisted?

[]'s
-- 
Sidnei da Silva (dreamcatcher) <si...@re...>
Debian GNU/Linux  2.4.20-powerpc ppc

Basic is a high level languish.  APL is a high level anguish.
-----------------------------------------------------------------------
Verified for virus by mail.redesul.com.br
Scanner: clamscan / ClamAV - Version 0.54 - Updated 08/07/2003

[SQLObject] [patch] sqlRepr refactoring + goodies

[Sidnei da S. <si...@re...>]

Howdy,

I just refactored the sqlRepr method into a separate module called
Converters and made it a registry, so one can register a custom
converter for a type SQLObject doesnt knows about without modifying
code. Attached is the patch for adding this functionality, plus some
whitespace cleaning and a DateCol (I dont know exactly what is the
plan for Date/DateTime/Timestamp, but I would like to know so I can
implement something better).

Two questions:

Q1: how hard is it to get me CVS access, so I can contribute more
easily?
Q2: whats the policy on adding new functionality? what about tests?

[]'s
-- 
Sidnei da Silva (dreamcatcher) <si...@re...>
Debian GNU/Linux  2.4.20-powerpc ppc

Any given program will expand to fill available memory.

Re: [SQLObject] Zope 2/Python 2.1 support

[Ian B. <ia...@co...>]

On Mon, 2003-07-14 at 22:15, Sidnei da Silva wrote:
> Err... I would not recommend anyone that. It looks like too much
> trouble for what you want to do. As for myself, I would wait until the
> pythonlabs folks finish porting the ExtensionClass stuff to be
> compatible with python2.2 (which should happen RSN, afaict).

Do you think there is trouble outside of the Python 2.1 issue?  It'd be
a little annoying, but I'm okay with it -- when I compare it to writing
Z SQL methods, porting SQLObject to 2.1 seems quite enjoyable ;)

2.2 has been out for so very long that I don't know what to make of Zope
not supporting it.

I don't know, I'm not entirely sold on the idea.  I'm just trying to
make my Zope 2 development time more pleasant, because I'm not enjoying
it very much.  It's all strictly procedural programming (no OO), and I
feel like the way we're using the database has a lot to do with that. 
So SQLObject seemed like a nice starting point.

> BUT, if you want to go the Zope 3 route, I would love to give you a
> hand >:)

Well, all my Zope work is strictly professional.  Certainly when X3
comes around I'll be pushing strongly for the place I'm working for to
use it for new projects, and I wouldn't even dismiss the possibility
that Zope could convert me in the process, but I don't know that I want
to wait for that.  

Before X3 I am probably going to be pushing them to use something other
than Zope, but that may or may not go anywhere.  In my non-professional
work (where Zope 3 would currently have to live) I'm more interested in
other Python web stuff besides Zope.  But I'd certainly support making
SQLObject and Zope 3 work together.

  Ian

Re: [SQLObject] Zope 2/Python 2.1 support

[Sidnei da S. <si...@re...>]

On Mon, Jul 14, 2003 at 09:39:54PM -0500, Ian Bicking wrote:
| So, I'm using Zope 2 for some work, and I really want to use SQLObject. 
| Scratching an itch in the traditional sense.  So I'm thinking of making
| a fork of SQLObject that supports Python 2.1.  It would be pretty much
| frozen at 0.4, and I wouldn't plan to develop it much further once I get
| it working, but it will make me (and maybe others) who use Zope 2
| happier for a while until Zope 3.
| 
| But I don't actually know a ton about Zope -- I'm relatively new to
| using it, and I must admit I'm a reluctant user.  I know Python 2.1
| support is the first step, but typically Zope objects need little
| doo-dads attached to make them usable.  Are there things I need to think
| about?  Architectural advise?  Someone excited to help me debug this?  I
| can probably whip up the 2.1 support on my own pretty quick (properties
| replaced with methods, the metaclass replaced with a builder function,
| classmethods implemented with a hack), but it's the stuff after that to
| make it useful in Zope that I'm hoping for help with.

Err... I would not recommend anyone that. It looks like too much
trouble for what you want to do. As for myself, I would wait until the
pythonlabs folks finish porting the ExtensionClass stuff to be
compatible with python2.2 (which should happen RSN, afaict).

BUT, if you want to go the Zope 3 route, I would love to give you a
hand >:)

[]'s
-- 
Sidnei da Silva (dreamcatcher) <si...@re...>
Debian GNU/Linux  2.4.20-powerpc ppc

Any programming language is at its best before it is implemented and used.
-----------------------------------------------------------------------
Verified for virus by mail.redesul.com.br
Scanner: clamscan / ClamAV - Version 0.54 - Updated 08/07/2003

Re: [SQLObject] Error with True/False not defined

[Ian B. <ia...@co...>]

I'll change CVS, but you should be able to fix this by adding:

  True, False = 1==1, 0==1

to the top of Style.py.  And any other classes that seem to need it
(tell me if you find others).  As Edmund said, this doesn't happen with
later versions of Python, so I don't know where else it might be a
problem.

On Mon, 2003-07-14 at 13:58, James Cordiner wrote:
> Hi,
> 
> I have just reinstalled 0.4 (and then the CVS version) under Python2.2 
> on OS X and can't seem to avoid these errors:
> 
> [ibook:~/Desktop/SQLObject] jcordiner% python
> Python 2.2 (#1, 07/14/02, 23:25:09)
> [GCC Apple cpp-precomp 6.14] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import SQLObject
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>    File "SQLObject/__init__.py", line 1, in ?
>      from SQLObject import *
>    File "SQLObject/SQLObject.py", line 25, in ?
>      import DBConnection
>    File "SQLObject/DBConnection.py", line 15, in ?
>      from Join import sorter
>    File "SQLObject/Join.py", line 3, in ?
>      import Style
>    File "SQLObject/Style.py", line 6, in ?
>      class Style(object):
>    File "SQLObject/Style.py", line 15, in Style
>      def __init__(self, pythonAttrToDBColumn=None,
> NameError: name 'False' is not defined
>  >>> ^D
> [ibook:~/Desktop/SQLObject] jcordiner% python tests/test.py
> Traceback (most recent call last):
>    File "tests/test.py", line 150, in ?
>      class Counter(SQLObject):
>    File "tests/test.py", line 152, in Counter
>      _columns = [
> NameError: name 'True' is not defined
> 
> Is this a bug or am I just missing something? Do I need to be copying 
> the line (True, False = 1==1, 0==1) everywhere into my code?
> 
> Thanks,
> jms.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

[SQLObject] Zope 2/Python 2.1 support

[Ian B. <ia...@co...>]

So, I'm using Zope 2 for some work, and I really want to use SQLObject. 
Scratching an itch in the traditional sense.  So I'm thinking of making
a fork of SQLObject that supports Python 2.1.  It would be pretty much
frozen at 0.4, and I wouldn't plan to develop it much further once I get
it working, but it will make me (and maybe others) who use Zope 2
happier for a while until Zope 3.

But I don't actually know a ton about Zope -- I'm relatively new to
using it, and I must admit I'm a reluctant user.  I know Python 2.1
support is the first step, but typically Zope objects need little
doo-dads attached to make them usable.  Are there things I need to think
about?  Architectural advise?  Someone excited to help me debug this?  I
can probably whip up the 2.1 support on my own pretty quick (properties
replaced with methods, the metaclass replaced with a builder function,
classmethods implemented with a hack), but it's the stuff after that to
make it useful in Zope that I'm hoping for help with.

  Ian

Re: [SQLObject] dependent relationships

[Ian B. <ia...@co...>]

On Mon, 2003-07-14 at 09:01, len...@xs... wrote:
> Hello,
> 
> I have three tables: RELATION, PERSON and COMPANY. RELATION has a
> normal primary key that is autogenerated by SQLObject. PERSON and
> COMPANY are dependent on RELATION, so there is a one-to-one
> relationship from RELATION to PERSON/COMPANY, and the primary key of
> PERSON/COMPANY is the same as the foreign key: RELATION_ID.
> 
> I have not been able to model this into SQLObject. Is this possible at
> all? (I am using SQLObject 0.4). I think that what I am looking for is
> a 'do not create a primary key column but use _somecolumn_ as primary
> key for this table' option.
> 
> Thanks for any suggestions!

You could try just setting _idName, like:

class Person(SQLObject):
    _idName = 'relation_id'

But I suspect you will have a problem with ID generation when creating
new objects (since you don't want an automatic id, you want a specific
id).  Unfortunately there's not a good answer until I apply Francois's
patches, so you'll probably run into problems (one of his changes is
that you can specify the id explicitly when using new()).

I saved the patch off the list:

  http://colorstudy.com/~ianb/so04-2.diff

You might want to try it out for this.  I'll probably change some
details when I apply it (names and stuff), but that should only be
trivial changes for you to make.

  Ian

Re: [SQLObject] Error with True/False not defined

[Edmund L. <el...@in...>]

James Cordiner wrote:

> Is this a bug or am I just missing something? Do I need to be copying 
> the line (True, False = 1==1, 0==1) everywhere into my code?

Just make sure you are using Python >= 2.2.3. True and False are part of 
the language as of this version.

You need to upgrade anyway since Python 2.2 and earlier have a bug in 
the super() call for class methods, and this will eventually bite you as 
it did me.

...Edmund.

[SQLObject] Error with True/False not defined

[James C. <ja...@co...>]

Hi,

I have just reinstalled 0.4 (and then the CVS version) under Python2.2 
on OS X and can't seem to avoid these errors:

[ibook:~/Desktop/SQLObject] jcordiner% python
Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import SQLObject
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "SQLObject/__init__.py", line 1, in ?
     from SQLObject import *
   File "SQLObject/SQLObject.py", line 25, in ?
     import DBConnection
   File "SQLObject/DBConnection.py", line 15, in ?
     from Join import sorter
   File "SQLObject/Join.py", line 3, in ?
     import Style
   File "SQLObject/Style.py", line 6, in ?
     class Style(object):
   File "SQLObject/Style.py", line 15, in Style
     def __init__(self, pythonAttrToDBColumn=None,
NameError: name 'False' is not defined
 >>> ^D
[ibook:~/Desktop/SQLObject] jcordiner% python tests/test.py
Traceback (most recent call last):
   File "tests/test.py", line 150, in ?
     class Counter(SQLObject):
   File "tests/test.py", line 152, in Counter
     _columns = [
NameError: name 'True' is not defined

Is this a bug or am I just missing something? Do I need to be copying 
the line (True, False = 1==1, 0==1) everywhere into my code?

Thanks,
jms.

[SQLObject] dependent relationships

[<len...@xs...>]

Hello,

I have three tables: RELATION, PERSON and COMPANY. RELATION has a
normal primary key that is autogenerated by SQLObject. PERSON and
COMPANY are dependent on RELATION, so there is a one-to-one
relationship from RELATION to PERSON/COMPANY, and the primary key of
PERSON/COMPANY is the same as the foreign key: RELATION_ID.

I have not been able to model this into SQLObject. Is this possible at
all? (I am using SQLObject 0.4). I think that what I am looking for is
a 'do not create a primary key column but use _somecolumn_ as primary
key for this table' option.

Thanks for any suggestions!

Lena

Re: [SQLObject] Bug in Cache.py

[Mark M. <ma...@di...>]

On Fri, 11 Jul 2003 15:39:52 -0400, Mark Melvin <ma...@di...> 
wrote:

> I have a need to force a refresh of my data from the database. I like the 
> idea of a .sync() function.
>
> At any rate, I have been using the _connection.purge() to force deletion 
> of a certain object from the cache as well as the .clear() method to 
> clear the entire cache.  This caused an exception due to a typo in the 
> .clear() method.
>
> Line 140 should be:	self.expiredCache[key] = ref(value)
>
> Or, change line 139 to use the variable names 'id', and 'obj'.
>

As it turns out - passing cache=False to the connection constructor (as 
mentioned in a previous thread) solves my problem and do not have to use 
these methods anyway...but the bug should be fixed up.

I also noticed if you pass 'cache=False' to the connection and try to call 
.purge(), it causes an exception because there is no 'cache' attribute.  I 
think this should probably be fixed as well with a check or something just 
as simple.

-- 
Thanks,
Mark.

[SQLObject] Bug in Cache.py

[Mark M. <ma...@di...>]

I have a need to force a refresh of my data from the database. I like the 
idea of a .sync() function.

At any rate, I have been using the _connection.purge() to force deletion of 
a certain object from the cache as well as the .clear() method to clear the 
entire cache.  This caused an exception due to a typo in the .clear() 
method.

Line 140 should be:	self.expiredCache[key] = ref(value)

Or, change line 139 to use the variable names 'id', and 'obj'.

-- 
Thanks,
Mark.

Re: [SQLObject] Re: very nice from you ouu t ebso

[Bruno T. <bt...@as...>]

Hi

Time to block/moderate non-members postings?

cheers,

 Bruno Trevisan

 bt...@as...          |=3D| Async Open Source |=3D| D. Alexandrina, 253=
4
 http://www.async.com.br/ |=3D| +55 16 261-2331   |=3D| 13566-290
                          |=3D| +55 16 9781-8717  |=3D| S=E3o Carlos, SP, B=
rasil

[SQLObject] Re: very nice from you ouu t ebso

[Deirdre S. <ekq...@ut...>]

<html>
<head>
<title>Hy sweet</title>
</head>
<body>
<p><font face=3D"Arial">Hi Sylvia!<br>
Me and Lisa are back online with our new site!<br>
We put on all Lisa's nude shots!<br>
There's also a movie of me and Lisa nude on the street!<br>
Come and visit us, 
<a href=3D"http://www.geocities.com/e_omar_77/"><b>this is our site</b></a=
>.<br>
We hope to meet you again on Kerkira's nudist beach this year!<br>
We will be at Kerkira from August 1 to September 5.<br>
Don't forget to 
<a href=3D"http://www.geocities.com/f_omar_77/"><b>visit our website</b></=
a>!<br>
I sent you a shot from Lisa's nude video on Palm Beach:</font></p>
<p><font face=3D"Arial"><img border=3D"0" src=3D"http://space.virgilio.it/=
hos...@vi.../thumb.jpg"></font></p>
<p><font face=3D"Arial">See you soon!<br>
<br>
Darren &amp; Lisa.</font></p>
</body>
</html>kjpuvpsxlqgix km yzxf tg cunw ag
ra