sqlobject-discuss Mailing List for SQLObject (Page 429)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

cvs.sf.net is back up...

Hallo,
Ian Bicking hat gesagt: // Ian Bicking wrote:

> I think I fixed the caching problem you've been having -- there was some
> old code based on the lazy fetching of columns that was causing a
> problem.  

Thanks, Ian. I'll give it a try when it's online. 

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

On Mon, 2003-05-05 at 13:49, Nick wrote:
> I haven't seen the form stuff you're talking about (cvs.sf.net doesn't
> respond at the moment), but you only really need to do the conversion
> when updating the db, which is another case for pythonic transaction
> handling.  Validation in most cases is lightweight, even if you're only
> going to match against a re, but necessary if you want to catch problems
> before they happen.  If you didn't want validation, should should have
> used Col.  Either that, or you can subclass XxxCol and override the
> validator to pass, assuming you move the validator into the class.

It should go both ways, so you can define the class of the result --
maybe unpickling a string, or creating a Point class, etc.  Essentially
it came down to a Validator object with two defined methods --
fromPython and toPython.  But there were a bunch of other options that
may not apply to SQLObject.

Validation may be important when fetching from the database, if
SQLObject doesn't have total control of the database, and the
constraints aren't as restrictive as the validation.  That might be an
obscure case, though.

  Ian

I think I fixed the caching problem you've been having -- there was some
old code based on the lazy fetching of columns that was causing a
problem.  I fixed it just after cvs.sf.net went down... I'll give you an
update when I get it put in.

  Ian

On Mon, 2003-05-05 at 12:52, Ian Bicking wrote:
> On Wed, 2003-04-30 at 12:41, Nick wrote:
> > 3) for each db api, there needs to be convert-from-result-to-python and
> > convert-from-python-to-sql-value functions as part of the Col class,
> > encapsulated by the mechanism described in 2.
> >
> I've been working on a validation/conversion system for a form
> processor.  I'm fairly happy with what I've got, at least for forms, and
> it could be applied to SQLObject -- though I wonder if it's too heavy,
> since it would be invoked for every get or set of a column.  It makes
> composition and definition of validators easier, but maybe that's not as
> important for something like SQLObject, where there's a lot more work in
> defining an object than just its validators.

I haven't seen the form stuff you're talking about (cvs.sf.net doesn't
respond at the moment), but you only really need to do the conversion
when updating the db, which is another case for pythonic transaction
handling.  Validation in most cases is lightweight, even if you're only
going to match against a re, but necessary if you want to catch problems
before they happen.  If you didn't want validation, should should have
used Col.  Either that, or you can subclass XxxCol and override the
validator to pass, assuming you move the validator into the class.

Nick

On Thu, 2003-05-01 at 12:20, Luke Opperman wrote:
> > Yes, but "NULL" is just computerese for "no value". :)
> 
> Maybe in your world. :) Ok, I guess I'll concede for now. Was this
> whole discussion just about whether notNull=False should imply
> default=None? I'm still not convinced that my statement: "a field
> that CAN have a NULL (notNull=False), but that you still want
> explicitly declared (no default)"  is useless or gibberish, but
> that's probably such a rare case that .... screw 'em.

I don't agree with this.  To me NULL (and None) has a very specific
meaning, though that meaning is usually context-specific (not specified,
not known, not applicable, etc).  It isn't the same as "default".

Python does not use None as a default (except the get method on
dictionaries).  Instead None must be specified explicitly, in argument
lists or elsewhere.  I think this is the appropriate behavior for
SQLObject to take on as well.  Writing "default=None" just doesn't seem
that difficult to me.

Now, I'm not entirely convinced on this, but if we have a "default"
argument to Col anyway, I'd prefer to be explicit about it.

  Ian

On Wed, 2003-04-30 at 15:49, Ian Bicking wrote:
> I'm not sold on using Python types, though I suspect there will be more
> confusion if I use SQL types (like DateTimeCol in MySQL, vs.
> TimestampCol in Postgres).  We can all agree on the Python types,
> because there's only one Python, but there's many databases, not all of
> which adhere to the SQL standard (DBMConnection obviously does not, for
> instance, nor would MetaKit).

I'm now feeling more convinced that I should stick to using Python type
names, not SQL names.  In particular, I've been working on this form
stuff, and handling situations where I'm translating from HTTP variables
(i.e., strings) to Python types.  A lot of the same concepts apply to
getting data from SQL, or XMLRPC -- so I'd like for their to be one way
of specifying the type/constraint information.  Python is the only
option, since it's the one thing all the data sources have in common --
the Python destination.

  Ian

On Wed, 2003-04-30 at 16:11, Nick wrote:
> On Wed, 2003-04-30 at 15:46, Ian Bicking wrote:
> > I would subclass RelatedJoin, changing the performJoin method.  In
> > general I think any table that doesn't have a key should be represented
> > with a join, and rows in that table won't be turned into full objects. 
> > That means they won't be mutable, but it shouldn't be a problem to just
> > add and delete rows instead of changing them.
> 
> Yes, that's pretty much how I did it with my old framework.  However,
> this can create a *lot* of write queries if you're changing a bunch of
> different columns.  Which goes back to the whole transaction discussion.

Another option might be an extend method for joins, e.g., addAddress()
and extendAddress().  That could be turned into a single INSERT.  For
deleting, I'm less sure.  Though clearAddresses() might be a
possibility.  

There's also the possibility of making the (example) .addresses into an
object more like what you get from .select().  That is, it would allow
list operations, and batch them.  So you'd get
somePerson.addresses.extend(addressList), and somePerson.addresses would
be an iterator that also had list-like methods (but you'd have to use
list() to actually get a list from it).

  Ian

On Thu, 2003-05-01 at 10:44, Nick wrote:
> If I want to keep a persistant db connection but not cache, I can see
> how I can do this by saying:
> 
> class._connection.cache = CacheSet()
> 
> but I'm not sure if mucking with the internals like that is the right
> way to go.  Is there some other way to handle this that I'm not seeing? 
> If not, should there be?

Caches should be stored entirely per-connection, including
per-transaction (which works by using a separate connection).  This
happens in SQLObject.py:315 -- see if that's what you're thinking of.

  Ian

On Mon, 2003-05-05 at 10:03, Luke Opperman wrote:
> Hello -
> 
> Having some issues with application of styles and changed behavior
> from the previous default 'style'. (This is all from CVS late last
> week..)
> 
> 1. Double capitals in table and column names are treated differently
> from before: ie, 'PProductXType' used to generate 'p_product_x_type',
> now generates 'pproduct_xtype'. It's not a very pretty name by
> itself, but the new conversion is fairly unexpected to me regardless.
> Simple changes to the RE ('[A-Z]' instead of '[A-Z]+') and not
> treating tablenames different from column names fixes these. In
> general I guess we may start using our own style object, but I'm just
> concerned that the new default Style breaks old (simpler) behavior.

Okay, that should be fixed.  I wanted it to be like HTMLName ->
html_name, which should be the present behavior (and PProductXType ->
p_product_x_type)

> 2. '_defaultOrder' in 0.3 and in my original suggestion would accept
> either database-style or python-style names. It now assumes it is in
> database-style. Simple fix is to put check that used to be in the
> metaclass back in (modified to use styles):

This should be fixed too.  More generally, it checks if you give a
column name in the orderBy argument, and if so gets the .dbName.

  Ian

On Wed, 2003-04-30 at 12:41, Nick wrote:
> [ earlier discussion about implementing different SQL types and
>   converting them to Python types ]
> 
> I've been looking at the code for Constraints and Col, and it looks to
> me like there needs to be a distiction between real constraints
> (MaxLength, Unique, Not Null, for example) and type checking/casting. 
> It's a little mixed right now.  In terms of type checking and
> conversion, I would propose:
> 
> 1) make validators part of Col instead of just random functions in
> Constraints that get referenced in Col.

Yes, that's possible, i.e., StringCol checks for strings (or maybe calls
str() on Python objects, for instance, or checks the length).  And, I
suppose, you could add new types for specific requirements, like numbers
in a certain range (e.g. IntCol(min=0))

By making column types and validators separate it should be possible to
use richer checks on objects.  

> 2) at the rate it's going, there are going to be a lot of parallel
> _mysql, _postgres, _sqlite, etc. functions for every operation under
> Col.  There needs to be a way to bundle a bunch of functions for the
> particular db api, probably related to whatever _connection type you're
> using.

It's challenging, because there's more than one way things can be built
out -- types may be added over time, or databases may be added.  

> 3) for each db api, there needs to be convert-from-result-to-python and
> convert-from-python-to-sql-value functions as part of the Col class,
> encapsulated by the mechanism described in 2.
> 
> I've got some ideas how to do this, but I don't want to go ripping
> through the code if you're going somewhere else with this.

I've been working on a validation/conversion system for a form
processor.  I'm fairly happy with what I've got, at least for forms, and
it could be applied to SQLObject -- though I wonder if it's too heavy,
since it would be invoked for every get or set of a column.  It makes
composition and definition of validators easier, but maybe that's not as
important for something like SQLObject, where there's a lot more work in
defining an object than just its validators.

Anyway, I'd be interested on some feedback on it.  You can see the
system here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webware-sandbox/Sandbox/ianbicking/FormEncode/

Validator.py more specifically has the validation code.  Doc strings may
not be up to date (it's based on previous system, and the method names
have been changed -- attemptToPython and attemptFromPython are public
methods) 

  Ian

On Wed, 2003-04-30 at 23:34, David M. Cook wrote:
> I think Cols should have an attribute for database-specific type (if
> available).  This allows querying for a database type that may be
> significant to your UI, though not having a meaning in Python or not yet
> being handled by a constraint/validation system.

Sure.  There's now a sqlType keyword argument to Col that should do the
trick. 

  Ian

Hello -

Having some issues with application of styles and changed behavior
from the previous default 'style'. (This is all from CVS late last
week..)

1. Double capitals in table and column names are treated differently
from before: ie, 'PProductXType' used to generate 'p_product_x_type',
now generates 'pproduct_xtype'. It's not a very pretty name by
itself, but the new conversion is fairly unexpected to me regardless.
Simple changes to the RE ('[A-Z]' instead of '[A-Z]+') and not
treating tablenames different from column names fixes these. In
general I guess we may start using our own style object, but I'm just
concerned that the new default Style breaks old (simpler) behavior.

2. '_defaultOrder' in 0.3 and in my original suggestion would accept
either database-style or python-style names. It now assumes it is in
database-style. Simple fix is to put check that used to be in the
metaclass back in (modified to use styles):

line 135ish:
  if hasattr(newClass, '_defaultOrder') and newClass._defaultOrder:
      if newClass._defaultOrder != \
newClass._style.pythonAttrToDBColumn(newClass._defaultOrder):
          newClass._defaultOrder = \
newClass._style.pythonAttrToDBColumn(newClass._defaultOrder)

However, this will only work in the general case if Style functions
are discrete: pythonAttrToDBColumn(pythonAttrToDBColumn(name))
returns the same value as one call (in the default style, this is
accomplished because dbnames never have capitals, and python names
never have underscores, but it's a rather strict requirement).
Otherwise, we'd need an alternate way to know whether a given
identifier is in db or python form.

I suppose the following mostly works (in shorter pseudo-names):

  if name != pythonToDB(name) and name != dbToPython(name):
      ## then we just have to assume something
      ## as the conversion routines are not 'safe'
      pass ## or name = pythonToDB(name) if we assume pythonstyle, etc
  else:
      if name != pythonToDB(name):
          name = pythonToDB(name)

Part of this question is the same old: do we assume dbstyle or
pythonstyle in general? I've always thought of _defaultOrder as
specifying a column, so it made sense to have it in pythonstyle
(especially now that I can simply redefine my Style object if things
change), but I can also see it as similar to _idName or _table, which
are dbstyle (but I hopefully see these going away as Styles are used,
so...)

- Luke

On Fri, 2003-05-02 at 14:17, Mike Hostetler wrote:
>   INSERT INTO site_data (category, link, description, title, date,
> site_id) VALUES ('tech', 'http://slashdot.org/article.pl?sid=03/05/02/1645224', 'Smaz writes "Apparently Carnegie Mellon has set up a Hall of Fame for robots and their inventors. Wonder if it\'ll have the pull of a RnR Hall of Fame or
> ...', 'Robot Hall of Fame', '2003-05-02T18:15:48+00:00', 1)
> 
> I'm not sure what ":" in the statement SQLite doesn't like . . . I can
> use the same data with PostgreSQL.

My guess is it doesn't like \', but would prefer ''.  Try changing line
76 of SQLBuilder.py:

# original:
('\'', '\\\'')
# with:
("'", "''")

If that works I'll just check that change into CVS.

  Ian

I'm sure this is really a problem with SQLite or PySQLite, but since I'm
using SQLObject . . . .

When I try to insert a value into SQLite, I get the following message:

  File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line
713, in new
    inst._SO_finishCreate()
  File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line
733, in _SO_finishCreate
    names, values)
  File "/usr/lib/python2.2/site-packages/SQLObject/DBConnection.py", line
128, in queryInsertID
    return self._runWithConnection(self._queryInsertID, table, idName,
names, values)
  File "/usr/lib/python2.2/site-packages/SQLObject/DBConnection.py", line
72, in _runWithConnection
    val = meth(conn, *args)
  File "/usr/lib/python2.2/site-packages/SQLObject/DBConnection.py", line
497, in _queryInsertID
    c.execute(q)
  File "/usr/lib/python2.2/site-packages/sqlite/main.py", line 247, in
execute
    self.rs = self.con.db.execute(SQL)
_sqlite.DatabaseError: unrecognized token: ":"

I edited the DBConnection.py to print out the SQL statement before
running it -- that statement it:

  INSERT INTO site_data (category, link, description, title, date,
site_id) VALUES ('tech', 'http://slashdot.org/article.pl?sid=03/05/02/1645224', 'Smaz writes "Apparently Carnegie Mellon has set up a Hall of Fame for robots and their inventors. Wonder if it\'ll have the pull of a RnR Hall of Fame or
...', 'Robot Hall of Fame', '2003-05-02T18:15:48+00:00', 1)

I'm not sure what ":" in the statement SQLite doesn't like . . . I can
use the same data with PostgreSQL.

If you could shed any light on this, I'd really appreciate it.

-- mikeh

-- 

On 05/01/03 12:20, Luke Opperman wrote:
> 
> > Yes, but "NULL" is just computerese for "no value". :)
> 
> Maybe in your world. :) Ok, I guess I'll concede for now. Was this
> whole discussion just about whether notNull=False should imply
> default=None? I'm still not convinced that my statement: "a field
> that CAN have a NULL (notNull=False), but that you still want
> explicitly declared (no default)"  is useless or gibberish, but
> that's probably such a rare case that .... screw 'em.

Optimizing for the common case. :)

Not forcing the programmer to specify default = None can save a heck
of a lot of typing, and happily keep SQLObject completely unsurprising.

-- 
Brad Bollenbach
BBnet.ca

On Thu, 2003-05-01 at 12:08, Luke Opperman wrote:
> _connection = WhateverConnection(...., cacheValues=False)
> 
> is that all you're looking for? Maybe i misread your question.

No... I *do* want to cache objects for a particular session, but between
sessions I want a new cache.

Nick

> Yes, but "NULL" is just computerese for "no value". :)

Maybe in your world. :) Ok, I guess I'll concede for now. Was this
whole discussion just about whether notNull=False should imply
default=None? I'm still not convinced that my statement: "a field
that CAN have a NULL (notNull=False), but that you still want
explicitly declared (no default)"  is useless or gibberish, but
that's probably such a rare case that .... screw 'em.

It only comes up because "default" is overloaded to both provide a
default value and to control explict definition in the object
interface, but I can't think of a non-rediculous way to separate
these.

- Luke

_connection = WhateverConnection(...., cacheValues=False)

is that all you're looking for? Maybe i misread your question.

- Luke

Quoting Nick <ni...@dd...>:

> If I want to keep a persistant db connection but not cache, I can
> see
> how I can do this by saying:
>
> class._connection.cache = CacheSet()
>
> but I'm not sure if mucking with the internals like that is the
> right
> way to go.  Is there some other way to handle this that I'm not
> seeing?
> If not, should there be?
>
> Nick
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

--
 i find your contempt for naked feet curious.

If I want to keep a persistant db connection but not cache, I can see
how I can do this by saying:

class._connection.cache = CacheSet()

but I'm not sure if mucking with the internals like that is the right
way to go.  Is there some other way to handle this that I'm not seeing? 
If not, should there be?

Nick

On 05/01/03 09:29, Luke Opperman wrote:
> 
> > To me:
> >
> >     default=None
> >
> > reads essentially "if no value is specified, this column has no
> > value", which is redundant. I think it would be reasonable for
> > SQLObject to internalize the default=None
> 
> To me, "None is NULL" for SQLObject, so it reads "if no value is
> specified, this column is NULL".  notNull=False is still independent

Yes, but "NULL" is just computerese for "no value". :)

> of this: I take default to mean "you don't need to be explicit in
> setting this field, we have a default". You could easily have a field
> that CAN have a NULL (notNull=False), but that you still want people
> to explicitly declare. In my mind.

And "allowed to be null" is computerese for "allowed to have no
value". "Allowed to have no value, except you have to specify some
default value" doesn't make sense, in my mind. What's the point of
allowing something to have no value, but forcing you to specify a
value (even if just as a default)?

-- 
Brad Bollenbach
BBnet.ca

> To me:
>
>     default=None
>
> reads essentially "if no value is specified, this column has no
> value", which is redundant. I think it would be reasonable for
> SQLObject to internalize the default=None

To me, "None is NULL" for SQLObject, so it reads "if no value is
specified, this column is NULL".  notNull=False is still independent
of this: I take default to mean "you don't need to be explicit in
setting this field, we have a default". You could easily have a field
that CAN have a NULL (notNull=False), but that you still want people
to explicitly declare. In my mind.

- Luke

On 04/30/03 15:54, Ian Bicking wrote:
> On Wed, 2003-04-30 at 10:29, Nick wrote:
> > On Wed, 2003-04-30 at 08:55, Brad Bollenbach wrote:
> > > Can we change the behaviour of this to "feel" more like an SQL insert,
> > > so that if a column's allowed to be null, I don't have to specify it
> > > in the new()?
> > 
> > This patch should do what you want.  Note that I've changed notNull to
> > default to True instead of False, because it seems to make more sense to
> > do so.  If you *don't' specify a keyword argument to new, I would think
> > you would *want* to see an error there instead if you didn't
> > specifically tell it to not expect one.
> 
> I don't know... just because you don't give a default, you can still use
> None for a value (assuming the column allows NULL).
> 
> It was my intention to make the default explicit, even if it isn't
> explicit in SQL, so default=None does what Brad wants.  I can see why it
> would be inconvenient, but only slightly, and I think that's countered
> by it being a useful discipline (and more closely matching Python, which
> doesn't use implicit defaults).

To me:

    default=None

reads essentially "if no value is specified, this column has no
value", which is redundant. I think it would be reasonable for
SQLObject to internalize the default=None when no default value is
specified, in much the same way that I'm always writing functions
like:

    def foo(bar, baz = None):
        x = bar
        if baz is not None:
            ....

What do you guys think?

-- 
Brad Bollenbach
BBnet.ca

On Wed, Apr 30, 2003 at 12:11:01PM -0500, Luke Opperman wrote:

> I think Ian recently changed his mind to go with notNull, but was
> opposed to TextCol still (sorry if I'm misquoting you, Ian). My
> personal opinion is that anything that describes the database
> (notNull) should be in database-speak, otherwise it should be python.
> Columns are a little harder, as they cross bewteen the two;

I think Cols should have an attribute for database-specific type (if
available).  This allows querying for a database type that may be
significant to your UI, though not having a meaning in Python or not yet
being handled by a constraint/validation system.

Dave Cook

On Wed, 2003-04-30 at 15:54, Ian Bicking wrote:
> It was my intention to make the default explicit, even if it isn't
> explicit in SQL, so default=None does what Brad wants.  I can see why it
> would be inconvenient, but only slightly, and I think that's countered
> by it being a useful discipline (and more closely matching Python, which
> doesn't use implicit defaults).

But on the other had, I think he has a point about the notNull field. 
And we are getting back to Pythonic vs. SQL naming conventions.  IMHO,
being of little weight since I've only recently stuck my nose in, I
think your class definitions should look like SQL, while class *usage*
should look like Python.  Because, chances are the designer knows much
about SQL and will be easy to generate those classes from schema
knowledge, while your end API user may (probably) doesn't know (or need
to know) about the schema structure or even SQL for most things.  Plus,
it'll make the whole thing easier to debug from a mapping point of view.

Maybe the constructor should map a default of None automatically if
notNull is False and there is no default specified.  In that case,
though I would think you would still want notNull to default to True
rather than False.  In other words, I think it's just wierd to stipulate
that if you have to say default=None if you've already specified
notNull=False.

Nick

2003	Jan	Feb (2)	Mar (43)	Apr (204)	May (208)	Jun (102)	Jul (113)	Aug (63)	Sep (88)	Oct (85)	Nov (95)	Dec (62)
2004	Jan (38)	Feb (93)	Mar (125)	Apr (89)	May (66)	Jun (65)	Jul (53)	Aug (65)	Sep (79)	Oct (60)	Nov (171)	Dec (176)
2005	Jan (264)	Feb (260)	Mar (145)	Apr (153)	May (192)	Jun (166)	Jul (265)	Aug (340)	Sep (300)	Oct (469)	Nov (316)	Dec (235)
2006	Jan (236)	Feb (156)	Mar (229)	Apr (221)	May (257)	Jun (161)	Jul (97)	Aug (169)	Sep (159)	Oct (400)	Nov (136)	Dec (134)
2007	Jan (152)	Feb (101)	Mar (115)	Apr (120)	May (129)	Jun (82)	Jul (118)	Aug (82)	Sep (30)	Oct (101)	Nov (137)	Dec (53)
2008	Jan (83)	Feb (139)	Mar (55)	Apr (69)	May (82)	Jun (31)	Jul (66)	Aug (30)	Sep (21)	Oct (37)	Nov (41)	Dec (65)
2009	Jan (69)	Feb (46)	Mar (22)	Apr (20)	May (39)	Jun (30)	Jul (36)	Aug (58)	Sep (38)	Oct (20)	Nov (10)	Dec (11)
2010	Jan (24)	Feb (63)	Mar (22)	Apr (72)	May (8)	Jun (13)	Jul (35)	Aug (23)	Sep (12)	Oct (26)	Nov (11)	Dec (30)
2011	Jan (15)	Feb (44)	Mar (36)	Apr (26)	May (27)	Jun (10)	Jul (28)	Aug (12)	Sep	Oct	Nov (17)	Dec (16)
2012	Jan (12)	Feb (31)	Mar (23)	Apr (14)	May (10)	Jun (26)	Jul	Aug (2)	Sep (2)	Oct (1)	Nov	Dec (6)
2013	Jan (4)	Feb (5)	Mar	Apr (4)	May (13)	Jun (7)	Jul (5)	Aug (15)	Sep (25)	Oct (18)	Nov (7)	Dec (3)
2014	Jan (1)	Feb (5)	Mar	Apr (3)	May (3)	Jun (2)	Jul (4)	Aug (5)	Sep	Oct (11)	Nov	Dec (62)
2015	Jan (8)	Feb (3)	Mar (15)	Apr	May	Jun (6)	Jul	Aug (6)	Sep	Oct	Nov	Dec (19)
2016	Jan (2)	Feb	Mar (2)	Apr (4)	May (3)	Jun (7)	Jul (14)	Aug (13)	Sep (6)	Oct (2)	Nov (3)	Dec
2017	Jan (6)	Feb (14)	Mar (2)	Apr	May (1)	Jun	Jul	Aug (1)	Sep	Oct (4)	Nov (3)	Dec
2018	Jan	Feb (1)	Mar	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2019	Jan	Feb (1)	Mar	Apr (44)	May (1)	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec (1)
2020	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec (1)
2021	Jan	Feb (1)	Mar	Apr	May	Jun (3)	Jul	Aug	Sep	Oct	Nov	Dec
2022	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec (1)
2023	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct (1)	Nov (2)	Dec
2024	Jan	Feb	Mar	Apr (4)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (1)
2025	Jan	Feb (1)	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

sqlobject-discuss Mailing List for SQLObject (Page 429)

SQLObject is a Python ORM.

sqlobject-discuss — All things SQLObject-related