sqlobject-discuss — All things SQLObject-related

[SQLObject] Python3 port status update

[Neil M. <drn...@gm...>]

For those not following github closely, there has been good progess on
the port to python 3. We are now down to only 3 test failures with
python3 and sqlite, and 4 with postgres. No-one's looked at trying to
run against mysql yet, I believe.

The failures in test_unicode are due to the changed unicode handling
in pyton 3, and the tests should probably be reworked for the python 3
behaviour.

The fialure in test_validiation is due to the handling of a custom
class with a __unicode__ method. I'm personally not sure how we should
handle these in python 3. Would it help people porting code to special
case __unicode__ in this case, or should we expect people to update to
using __str__ ?

Regardless of the outstanding test failures, I think the port is at a
point whee it would benefit from more people using and looking at the
code.

-- 
Neil Muller
drn...@gm...

I've got a gmail account. Why haven't I become cool?

[SQLObject] Sphinx docs

[Oleg B. <ph...@ph...>]

Hello! I've just created a branch sphinx-docs. The docs are published at
https://sqlobject.readthedocs.org/ . The branch needs some help from
people with knowledge of Sphinx.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] flake8 cleanness

[Oleg B. <ph...@ph...>]

Hello!

   With a few exceptions master branch is now flake8-clean (and hence
pep8-clean) for Python 2. flake8-cleanness for commits is now a
requirement. Please consider using pre-commit hook installed by running
   flake8 --install-hook
Don't forget though that older branches are still maintained but are not
flake8-clean.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject 2.1.0

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce version 2.1.0, the first stable release of branch
2.1 of SQLObject.


What's new in SQLObject
=======================

Minor features
--------------

* In queries generated with SQLObject's tables columns are sorted in the
  order they are declared in the table.

* In queries generated with sqlbuilder's Insert/Update, if values are
  passed using dictionaries, columns are sorted alphabetically.

* Tables in SELECT...FROM clause are sorted alphabetically.

* MySQLConnection, PostgresConnection and SQLiteConnection have got
  a new method listDatabases() that lists databases in the connection
  and returns a list of names.

* MySQLConnection, PostgresConnection and SQLiteConnection have got
  a new method listTables() that returns a list of table names in the database.

Contributor for this release is Ian Cordasco.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).

Python 2.6 or 2.7 is required.


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/2.1.0

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Flake8 fixes

[Oleg B. <ph...@ph...>]

On Mon, Jan 05, 2015 at 07:50:34AM -0600, Ian Cordasco <gra...@gm...> wrote:
> On Mon, Jan 5, 2015 at 6:50 AM, Oleg Broytman <ph...@ph...> wrote:
> >    Ian Cordasco and I split the work on flake8 fixes by error number. If
> > you want to help developing SQLObject see issues marked with [flake8] at
> > https://github.com/sqlobject/sqlobject/issues
> >
> >    The recommended workflow:
> >
> > 1. Announce here you want to work on an issue; I'll assign the issue to
> > you. This is to avoid duplication of effort.
> 
> FWIW, this is (in my opinion) the biggest limitation of GitHub's issue
> tracking system. You can only assign an issue to someone who has push
> access to the repository.

   We can mark the "ownership" in a comment to the issue.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Flake8 fixes

[Ian C. <gra...@gm...>]

On Mon, Jan 5, 2015 at 6:50 AM, Oleg Broytman <ph...@ph...> wrote:
> Hello, All!
>
>    Ian Cordasco and I split the work on flake8 fixes by error number. If
> you want to help developing SQLObject see issues marked with [flake8] at
> https://github.com/sqlobject/sqlobject/issues . The simpler issues
> (lower number of lines) are also labeled "low-hanging fruit":
> https://github.com/sqlobject/sqlobject/issues?q=is%3Aopen+label%3A%22low-hanging+fruit%22
>
>    The recommended workflow:
>
> 1. Announce here you want to work on an issue; I'll assign the issue to
> you. This is to avoid duplication of effort.

FWIW, this is (in my opinion) the biggest limitation of GitHub's issue
tracking system. You can only assign an issue to someone who has push
access to the repository.

> 2. Fix the problems in the code. If the description in the issue isn't
> detailed enough -- I can show the exact lines in the files.
>
> 3. Test with flake8 (I use vim-flake8 plugin but that's up to you). If
> the error is ignored in setup.cfg -- remove it before testing; remove
> both the comment and the error from "ignore" list.
>
> 3. Commit to branch "flake8-fixes"; do ``git pull --rebase`` before
> pushing, then ``git push origin flake8-fixes``. Create a pull request
> from your commit.

If you do not want to use GitHub, you can do:

   git format-patch -n HEAD^

And then email the list with the patch file. I, or someone else will
be able to apply it and create a PR for you. You will still appear as
the author and receive credit for your work.

> 4. Please do one commit per issue. The biggest issues (with hundreds
> lines) perhaps require a few commits. Make your commit message something
> like "Fix #xxx flake8 Eyyy", where #xxx is the issue's number and yyy is
> the error; for example "Fix #50 flake8 E401". "Fix #xxx" makes github
> automatically close the issue.
>
>    The list of errors sorted by the number of lines:
>
>     825 E302
>     469 E501
>     168 F403
>     149 E265
>     123 E225
>     120 E128
>     116 E301
>      72 E261
>      68 E231
>      43 F841
>      42 F401
>      40 E127
>      36 E701
>      33 E221
>      27 E502
>      27 E126
>      26 F821
>      22 E202
>      22 E201
>      19 W293
>      16 E129
>      16 E111
>      11 F402
>      11 E303
>      11 E203
>       9 W391
>       9 E122
>       8 E251
>       7 W291
>       7 E713
>       6 W603
>       6 E124
>       5 E712
>       5 E711
>       5 E228
>       4 E271
>       4 E211
>       4 E121
>       3 F812
>       3 E401
>       3 E222
>       2 F822
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Re: [SQLObject] Transaction docs

[Oleg B. <ph...@ph...>]

On Mon, Jan 05, 2015 at 02:26:57PM +0100, Gregor Horvath <gh...@gr...> wrote:
> Hi Oleg,
> 
> Am Mon, 5 Jan 2015 13:19:39 +0100
> schrieb Oleg Broytman <ph...@ph...>:
> > On Mon, Jan 05, 2015 at 12:19:20PM +0100, Gregor Horvath
> > <gh...@gr...> wrote:
> 
> >    Creating a transaction doesn't automatically use that transaction
> > -- you have to use the new transaction object as a connection. So your
> 
> Thank you very much for your fast and comprehensive answer!
> No I understand and it works.
> 
> To clarify this I would like to update the docs:
> 
> http://sqlobject.org/SQLObject.html#transactions
> 
> with for example adding your sentence:
> 
> "Creating a transaction doesn't automatically use that transaction 
> you have to use the new transaction object as a connection."
> 
> I did not found a repository for the docs.
> How can I contribute this to it?

   There is no a separate repository for the docs -- docs are in the
main repository: https://github.com/sqlobject/sqlobject/ . Mostly it's
because that the way the sources were organized in Subversion and
partially because docs are version-dependent (the news, the list of
contributors and major features certainly are).

   Please, create a PR against branch 1.6 (it's the oldest supported
branch), I'll merge it upward. Thank you in advance!

> --
> Greg

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] autoCommit=False and Transaction -> SQLObjectNotFound on creation

[Gregor H. <gh...@gr...>]

Hi Oleg,

Am Mon, 5 Jan 2015 13:19:39 +0100
schrieb Oleg Broytman <ph...@ph...>:

> On Mon, Jan 05, 2015 at 12:19:20PM +0100, Gregor Horvath
> <gh...@gr...> wrote:
> > Problem: 
> > 
> >     raise SQLObjectNotFound, "The object %s by the ID %s does not
> >  exist" % (self.__class__.__name__, self.id)
> > sqlobject.main.SQLObjectNotFound: The object Eingangsrechnung by
> > the ID 1 does not exist

>    Creating a transaction doesn't automatically use that transaction
> -- you have to use the new transaction object as a connection. So your

Thank you very much for your fast and comprehensive answer!
No I understand and it works.

To clarify this I would like to update the docs:

http://sqlobject.org/SQLObject.html#transactions

with for example adding your sentence:

"Creating a transaction doesn't automatically use that transaction 
you have to use the new transaction object as a connection."

I did not found a repository for the docs.
How can I contribute this to it?

--
Greg                                   

[SQLObject] Flake8 fixes

[Oleg B. <ph...@ph...>]

Hello, All!

   Ian Cordasco and I split the work on flake8 fixes by error number. If
you want to help developing SQLObject see issues marked with [flake8] at
https://github.com/sqlobject/sqlobject/issues . The simpler issues
(lower number of lines) are also labeled "low-hanging fruit":
https://github.com/sqlobject/sqlobject/issues?q=is%3Aopen+label%3A%22low-hanging+fruit%22

   The recommended workflow:

1. Announce here you want to work on an issue; I'll assign the issue to
you. This is to avoid duplication of effort.

2. Fix the problems in the code. If the description in the issue isn't
detailed enough -- I can show the exact lines in the files.

3. Test with flake8 (I use vim-flake8 plugin but that's up to you). If
the error is ignored in setup.cfg -- remove it before testing; remove
both the comment and the error from "ignore" list.

3. Commit to branch "flake8-fixes"; do ``git pull --rebase`` before
pushing, then ``git push origin flake8-fixes``. Create a pull request
from your commit.

4. Please do one commit per issue. The biggest issues (with hundreds
lines) perhaps require a few commits. Make your commit message something
like "Fix #xxx flake8 Eyyy", where #xxx is the issue's number and yyy is
the error; for example "Fix #50 flake8 E401". "Fix #xxx" makes github
automatically close the issue.

   The list of errors sorted by the number of lines:

    825 E302
    469 E501
    168 F403
    149 E265
    123 E225
    120 E128
    116 E301
     72 E261
     68 E231
     43 F841
     42 F401
     40 E127
     36 E701
     33 E221
     27 E502
     27 E126
     26 F821
     22 E202
     22 E201
     19 W293
     16 E129
     16 E111
     11 F402
     11 E303
     11 E203
      9 W391
      9 E122
      8 E251
      7 W291
      7 E713
      6 W603
      6 E124
      5 E712
      5 E711
      5 E228
      4 E271
      4 E211
      4 E121
      3 F812
      3 E401
      3 E222
      2 F822

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] autoCommit=False and Transaction -> SQLObjectNotFound on creation

[Oleg B. <ph...@ph...>]

Hi!

On Mon, Jan 05, 2015 at 12:19:20PM +0100, Gregor Horvath <gh...@gr...> wrote:
> Problem: 
> 
>     raise SQLObjectNotFound, "The object %s by the ID %s does not
>  exist" % (self.__class__.__name__, self.id)
> sqlobject.main.SQLObjectNotFound: The object Eingangsrechnung by the ID
> 1 does not exist
> 
> --------------------
> 
> sqlhub.processConnection.autoCommit = False
> t = Person._connection.transaction()
> er = Eingangsrechnung(name="test")
> pr = Person(name="test")
> Buchung(person=pr, eingangsrechnung=er)
> t.commit()
> 
> ----
> Greg

   With SQLObject you can open a dozen different connections to the same
or different backends. Because of that you have to explicitly set your
desired connection for any select/create operation (after select/create
the object remembers its connection and uses it for update/delete); if
you don't set connection explicitly sqlhub is used.
   Creating a transaction doesn't automatically use that transaction --
you have to use the new transaction object as a connection. So your
options are:

1. Assign the transaction to sqlhub:

the new t = Person._connection.transaction()
sqlhub.processConnection = t # <= !!!
er = Eingangsrechnung(name="test")
pr = Person(name="test")
Buchung(person=pr, eingangsrechnung=er)
t.commit()

   Don't forget to set the original connection back at the end:

sqlhub.processConnection = initialConnection

2. Use the transaction explicitly:

t = Person._connection.transaction()
er = Eingangsrechnung(name="test", connection=t)
pr = Person(name="test", connection=t)
Buchung(person=pr, eingangsrechnung=er, connection=t)
t.commit()

3. Rewrite you code as a function and use sqlhub.doInTransaction(f);
doInTransaction creates and commits a transaction for you, no need to
create t.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] autoCommit=False and Transaction -> SQLObjectNotFound on creation

[Gregor H. <gh...@gr...>]

Hello,

Problem: 

$ dropdb scratch; createdb scratch; python /tmp/scratch.py 
Traceback (most recent call last):
  File "/tmp/scratch.py", line 25, in <module>
    er = Eingangsrechnung(name="test")
  File
 "/home/gregor/work/gnucash/testve/local/lib/python2.7/site-packages/sqlobject/main.py",
line 1226, in __init__
    self._create(id, **kw)
  File
 "/home/gregor/work/gnucash/testve/local/lib/python2.7/site-packages/sqlobject/main.py",
line 1274, in _create
    self._SO_finishCreate(id)
  File
 "/home/gregor/work/gnucash/testve/local/lib/python2.7/site-packages/sqlobject/main.py",
line 1301, in _SO_finishCreate
    self._init(id)
  File
 "/home/gregor/work/gnucash/testve/local/lib/python2.7/site-packages/sqlobject/main.py",
line 934, in _init
    raise SQLObjectNotFound, "The object %s by the ID %s does not
 exist" % (self.__class__.__name__, self.id)
sqlobject.main.SQLObjectNotFound: The object Eingangsrechnung by the ID
1 does not exist

--------------------

$ cat /tmp/scratch.py 
from sqlobject import SQLObject, sqlhub, connectionForURI, ForeignKey,
StringCol

sqlhub.processConnection =
connectionForURI('postgres://gregor@localhost/scratch?debug=0&autoCommit=1')

class Person(SQLObject):
     name = StringCol()

class Eingangsrechnung(SQLObject):
     name = StringCol()

class Buchung(SQLObject): 
     eingangsrechnung = ForeignKey('Eingangsrechnung')
     person = ForeignKey('Person')


Person.createTable()
Eingangsrechnung.createTable()
Buchung.createTable()

sqlhub.processConnection.autoCommit = False
t = Person._connection.transaction()
er = Eingangsrechnung(name="test")
pr = Person(name="test")
Buchung(person=pr, eingangsrechnung=er)
t.commit()

----

It works if I remove the transaction lines, or set autoCommit =True. 
I have tested this with SQLObject 0.12.4 and 2.0.0, same behaviour.
Is this a bug, or do I do something wrong?

--
Greg

Re: [SQLObject] Accumulation functions over limited results

[Michael R. <mi...@ti...>]

Happy to take a stab at making a patch.  Mostly, I wanted to see if the 
community thought it was a good idea before I took the time.

-miker


On 12/30/2014 12:18 PM, Oleg Broytman wrote:
> Hello!
>
> On Tue, Dec 30, 2014 at 09:53:45AM -0800, Michael Root <mi...@ti...> wrote:
>> Ran into an issue the other day, which I think could be described as a bug, or
>> perhaps a mis-feature, depending on how you look at it.
>>
>> If you use an accumulator function on a SelectResults object (sum, avg, etc.),
>> it will silently do the "wrong thing" if that SelectResults object has a LIMIT
>> in it.
>>
>> Now, I understand that adding a LIMIT to a standard SQL query won't affect the
>> result either:
>>
>>       SELECT AVG(size) FROM Thing ORDER BY size LIMIT 5
>>
>> This will return the average size of all rows, not just the smallest 5, as if
>> the ORDER BY and LIMIT weren't there at all.  In this sense, the current
>> behavior of SQLObject is correct.
>>
>> However, consider this code:
>>
>>       class Thing(SQLObject):
>>           size = IntCol()
>>
>>       things = [Thing(size=n) for n in range(10)]
>>
>>       allThings = Thing.select()
>>       smallThings = allThings.orderBy(Thing.q.size).limit(5)
>>       bigThings = allThings.orderBy(Thing.q.size).reversed().limit(5)
>>       evenThings = allThings.filter(Thing.q.size % 2 == 0)
>>
>>       print allThings.avg(Thing.q.size)
>>       print smallThings.avg(Thing.q.size)
>>       print bigThings.avg(Thing.q.size)
>>       print evenThings.avg(Thing.q.size)
>>
>> In this case, iterating over any of these SelectResults objects works as you
>> would expect, but the values returned by accumulators on smallThings and
>> bigThings are "wrong".
>>
>> So, my question is, would it be reasonable for SQLObject to automatically detect
>> this, and form a subquery?  A query like this yields the correct results:
>>
>>       SELECT AVG(size) FROM (SELECT size FROM Thing ORDER BY SIZE LIMIT 5) AS _tmp
>>
>> If so, it would make user code much easier to read/write, as compared to using
>> sqlbuilder to do the same thing.  I was able to do it, but it was painfully
>> awkward and ugly.
>     Quite an interesting idea! Do you want to try to implement it and
> produce a patch (a pull request)?
>
>> Alternatively, if that's not possible, maybe at least throw an exception similar
>> to .limit(n).count()?
>>
>> Cheers,
>> -miker
>>
>> P.S. Been a long-time SQLObject user--it's one of my favorite Python things.
>> Thanks, Oleg, for all your hard work on it.  :)
>     You are welcome!
>
> Oleg.

Re: [SQLObject] Accumulation functions over limited results

[Oleg B. <ph...@ph...>]

Hello!

On Tue, Dec 30, 2014 at 09:53:45AM -0800, Michael Root <mi...@ti...> wrote:
> Ran into an issue the other day, which I think could be described as a bug, or 
> perhaps a mis-feature, depending on how you look at it.
> 
> If you use an accumulator function on a SelectResults object (sum, avg, etc.), 
> it will silently do the "wrong thing" if that SelectResults object has a LIMIT 
> in it.
> 
> Now, I understand that adding a LIMIT to a standard SQL query won't affect the 
> result either:
> 
>      SELECT AVG(size) FROM Thing ORDER BY size LIMIT 5
> 
> This will return the average size of all rows, not just the smallest 5, as if 
> the ORDER BY and LIMIT weren't there at all.  In this sense, the current 
> behavior of SQLObject is correct.
> 
> However, consider this code:
> 
>      class Thing(SQLObject):
>          size = IntCol()
> 
>      things = [Thing(size=n) for n in range(10)]
> 
>      allThings = Thing.select()
>      smallThings = allThings.orderBy(Thing.q.size).limit(5)
>      bigThings = allThings.orderBy(Thing.q.size).reversed().limit(5)
>      evenThings = allThings.filter(Thing.q.size % 2 == 0)
> 
>      print allThings.avg(Thing.q.size)
>      print smallThings.avg(Thing.q.size)
>      print bigThings.avg(Thing.q.size)
>      print evenThings.avg(Thing.q.size)
> 
> In this case, iterating over any of these SelectResults objects works as you 
> would expect, but the values returned by accumulators on smallThings and 
> bigThings are "wrong".
> 
> So, my question is, would it be reasonable for SQLObject to automatically detect 
> this, and form a subquery?  A query like this yields the correct results:
> 
>      SELECT AVG(size) FROM (SELECT size FROM Thing ORDER BY SIZE LIMIT 5) AS _tmp
> 
> If so, it would make user code much easier to read/write, as compared to using 
> sqlbuilder to do the same thing.  I was able to do it, but it was painfully 
> awkward and ugly.

   Quite an interesting idea! Do you want to try to implement it and
produce a patch (a pull request)?

> Alternatively, if that's not possible, maybe at least throw an exception similar 
> to .limit(n).count()?
> 
> Cheers,
> -miker
> 
> P.S. Been a long-time SQLObject user--it's one of my favorite Python things.  
> Thanks, Oleg, for all your hard work on it.  :)

   You are welcome!

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Accumulation functions over limited results

[Michael R. <mi...@ti...>]

Hi.

Ran into an issue the other day, which I think could be described as a bug, or 
perhaps a mis-feature, depending on how you look at it.

If you use an accumulator function on a SelectResults object (sum, avg, etc.), 
it will silently do the "wrong thing" if that SelectResults object has a LIMIT 
in it.

Now, I understand that adding a LIMIT to a standard SQL query won't affect the 
result either:

     SELECT AVG(size) FROM Thing ORDER BY size LIMIT 5

This will return the average size of all rows, not just the smallest 5, as if 
the ORDER BY and LIMIT weren't there at all.  In this sense, the current 
behavior of SQLObject is correct.

However, consider this code:

     class Thing(SQLObject):
         size = IntCol()

     things = [Thing(size=n) for n in range(10)]

     allThings = Thing.select()
     smallThings = allThings.orderBy(Thing.q.size).limit(5)
     bigThings = allThings.orderBy(Thing.q.size).reversed().limit(5)
     evenThings = allThings.filter(Thing.q.size % 2 == 0)

     print allThings.avg(Thing.q.size)
     print smallThings.avg(Thing.q.size)
     print bigThings.avg(Thing.q.size)
     print evenThings.avg(Thing.q.size)

In this case, iterating over any of these SelectResults objects works as you 
would expect, but the values returned by accumulators on smallThings and 
bigThings are "wrong".

So, my question is, would it be reasonable for SQLObject to automatically detect 
this, and form a subquery?  A query like this yields the correct results:

     SELECT AVG(size) FROM (SELECT size FROM Thing ORDER BY SIZE LIMIT 5) AS _tmp

If so, it would make user code much easier to read/write, as compared to using 
sqlbuilder to do the same thing.  I was able to do it, but it was painfully 
awkward and ugly.

Alternatively, if that's not possible, maybe at least throw an exception similar 
to .limit(n).count()?

Cheers,
-miker

P.S. Been a long-time SQLObject user--it's one of my favorite Python things.  
Thanks, Oleg, for all your hard work on it.  :)

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

Ian, if you publish here the list of current tasks people could select
some tasks or subtasks to help you.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] SQLObject status

[Oleg B. <ph...@ph...>]

Hi, All!

On Sat, Dec 20, 2014 at 07:19:33PM +0100, Oleg Broytman <ph...@ph...> wrote:
> I'm pleased to announce version 2.0.0, the first stable release of branch
> 2.0 of SQLObject.

   With this release I'm stopping supporting branch 1.5. Branch 1.6 is
in maintenance mode -- I'll apply patches if there will be patches.
Branches 1.7 and 2.0 are in active maintenance mode -- I'll try to fix
bugs if there will be bug reports. Branches 2.1 and 3.0 are in
development.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Ian C. <gra...@gm...>]

On Thu, Dec 11, 2014 at 8:13 AM, Ian Cordasco
<gra...@gm...> wrote:
> Awesome!
>
> On Dec 11, 2014 8:10 AM, "Oleg Broytman" <ph...@ph...> wrote:
>>
>> On Wed, Dec 10, 2014 at 12:55:36AM +0100, Oleg Broytman <ph...@ph...>
>> wrote:
>> > create a separate branch for 2.0. Then master will be free for working
>> > on Py3 compatibility.
>>
>>    Done: I created a new branch 2.0 and edited master to be 3.0
>> pre-alpha.
>>
>>    Ian, the master is waiting for you! ;-)
>>
>> Oleg.
>> --
>>      Oleg Broytman            http://phdru.name/            ph...@ph...
>>            Programmers don't die, they just GOSUB without RETURN.
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sqlobject-discuss mailing list
>> sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss


So I finally got some time. I've put together
https://github.com/sqlobject/sqlobject/pull/1 so we can have something
that everyone can reproduce with. It's uncovered a couple bugs in the
tests (specifically around depending on hash/dictionary ordering).
That aside, there are a bunch of problems pyflakes has with the
code-base but just running the py34 version has found syntactical
incompatibilities that should be easy to fix. I'd like to do that in a
separate pull request.

I'd like everyone's thoughts on this. This particular strategy is
something a lot of projects are beginning to use. I feel like we
should also add some documentation around running the tests
(especially for people who don't deal with postgres often (like me)
;)).

Cheers,
Ian

[SQLObject] SQLObject 2.0

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce version 2.0.0, the first stable release of branch
2.0 of SQLObject.


What's new in SQLObject
=======================

Features & Interface
--------------------

* DateTimeCol and TimeCol can read and write values with microseconds.

  WARNING: microseconds are supported by MariaDB since version 5.3.0 and
  by MySQL since version 5.6.4, and even these versions require special
  handling: columns to store microseconds have to be declared with
  precision 6: TIME(6), DATETIME(6), TIMESTAMP(6). SQLObject does the
  right thing when creating a new database but existing databases have
  to be changed: run something like
  ``ALTER TABLE name MODIFY COLUMN col TIME(6)`` for every column that
  you want to store microseconds.

  WARNING: backward compatibility problem! Date/Time columns created
  with microseconds cannot be read back from SQLite databases (and
  perhaps other backends) with versions of SQLObject older than 1.7.

Minor features
--------------

* PostgresConnection, when used with fromDatabase=True, sets alternateID
  for unique columns.

* Extend sdist: include everything (even generated html)
  into source distribution.

* Extend setup.py: include docs and tests into the egg.

Development
-----------

* Development was switched from Subversion to git.

Documentation
-------------

* Old news were restored back to version 0.2.1.

* News.txt was split into 5 small files.

Contributors for this release are Andrew Trusty and Jared Jennings.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).

Python 2.6 or 2.7 is required.


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/2.0.0

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject 1.7.3

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce version 1.7.3, a release with minor
documentation update of branch 1.7 of SQLObject.


What's new in SQLObject
=======================

* Extend setup.py: include docs and tests into the egg.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).

Python 2.6 or 2.7 is required.


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/1.7.3

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject 1.6.4

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce version 1.6.4, a release with minor
documentation update of branch 1.6 of SQLObject.


What's new in SQLObject
=======================

* Extend setup.py: include docs and tests into the egg.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).

Python 2.5 or higher is required.


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/1.6.4

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject 1.5.6

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce version 1.5.6, a release with minor
documentation update of branch 1.5 of SQLObject.


What's new in SQLObject
=======================

* Extend setup.py: include docs and tests into the egg.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).

Python 2.4 or higher is required.


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/1.5.6

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject 1.7.2

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce version 1.7.2, a bugfix release of branch
1.7 of SQLObject.


What's new in SQLObject
=======================

* Fix a bug: zero-pad microseconds on the right, not on the left; 0.0835
  seconds means 83500 microseconds.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/1.7.2

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Ian C. <gra...@gm...>]

Awesome!
On Dec 11, 2014 8:10 AM, "Oleg Broytman" <ph...@ph...> wrote:

> On Wed, Dec 10, 2014 at 12:55:36AM +0100, Oleg Broytman <ph...@ph...>
> wrote:
> > create a separate branch for 2.0. Then master will be free for working
> > on Py3 compatibility.
>
>    Done: I created a new branch 2.0 and edited master to be 3.0
> pre-alpha.
>
>    Ian, the master is waiting for you! ;-)
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

On Wed, Dec 10, 2014 at 12:55:36AM +0100, Oleg Broytman <ph...@ph...> wrote:
> create a separate branch for 2.0. Then master will be free for working
> on Py3 compatibility.

   Done: I created a new branch 2.0 and edited master to be 3.0
pre-alpha.

   Ian, the master is waiting for you! ;-)

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

On Wed, Dec 10, 2014 at 12:55:36AM +0100, Oleg Broytman <ph...@ph...> wrote:
>    There is one sporadic bug related to round number of microseconds
> like 83500: some parts of code think it's 0.0835 (83500), and some think
> it's 0.835 (835000). See the traceback near the end of
> https://travis-ci.org/sqlobject/sqlobject/jobs/42989776

   Fixed. The problem was in converter.py: I used "%d" format to convert
microseconds to SQL strings where it really must be "%06d".

   SQLObject 2.0 beta 1 was just released. All tests passed, see

   https://travis-ci.org/sqlobject/sqlobject/builds/43712156

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.