sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Connection errors

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

Hi!

On Thu, Sep 12, 2013 at 02:07:48PM -0300, Francisco Chiotta <fra...@gm...> wrote:
> Hello,
>         I have a question related with the connections. I am using the
> following code for that:
> 
> try:
>      connection = connectionForURI('postgres://'+user+':'+password+'@
> '+host+'/'+database)
>      sqlhub.processConnection = connection
>      connection.query("SELECT 1")
> except OperationalError:
>      print "error"
> 
> but, I don't know if the error is because the user and password are wrong
> or the sever is not working. How can I verify that? for example, maybe,
> with a error code but I don't know how to get it.

   Hope this helps:

except OperationalError, e:
     print "error:", e

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

[SQLObject] Connection errors

[Francisco C. <fra...@gm...>]

Hello,
        I have a question related with the connections. I am using the
following code for that:

try:
     connection = connectionForURI('postgres://'+user+':'+password+'@
'+host+'/'+database)
     sqlhub.processConnection = connection
     connection.query("SELECT 1")
except OperationalError:
     print "error"

but, I don't know if the error is because the user and password are wrong
or the sever is not working. How can I verify that? for example, maybe,
with a error code but I don't know how to get it.

Cheers,

Re: [SQLObject] Saving a rol with a derivative atribute

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

On Wed, Sep 11, 2013 at 06:29:57PM +0400, Oleg Broytman <ph...@ph...> wrote:
>    If you only need to set the default once you can override method
> __init__ in your class, set the default and call parent's __init__. You
> can also override .set() but simple assignment like
> 
>     row.title = new_value
> 
> doesn't call 'set(). If you want to catch all assignments events is the
> only route.

   And, BTW, overriding ._create() would be simpler than __init__.

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

Re: [SQLObject] Saving a rol with a derivative atribute

[Georgio B. <geo...@gm...>]

Oleg, thank you for the clarification, once I have learned a bit about
signals I will submit a patch to improve the documentation


2013/9/11 Oleg Broytman <ph...@ph...>

> Hi!
>
> On Wed, Sep 11, 2013 at 10:25:31AM -0300, Georgio Barbosa <
> geo...@gm...> wrote:
> > I would like to know if it is possible to create a model class with a
> > default attribute derived from another.
> >
> > An example:
> >
> > class Post(SQLObject):
> > *title = StringCol()*
> > content = StringCol()
> > create_time = DateTimeCol(default=datetime.now)
> > tags = RelatedJoin('Tag')
> > author = ForeignKey('Author')
> > *slug = StringCol(default=title.replace(" ", "-"))*
>
>    It is possible but in a rather complex non-obvious way. You have to
> use events (signals); unfortunately that gem of SQLObject is
> underdocumented (to say mildly), so you need to consult the code.
>    See http://sqlobject.org/SQLObject.html#events-signals for the
> starting point. Read events.py and lookup main.py to see how signals are
> sent and how SQLObject uses returned values.
>    You need to catch RowCreateSignal and RowUpdateSignal -- they are
> sent before INSERT and UPDATE correspondingly -- and update values to
> your need in your signal handlers.
>
>    It would be great if after you learn the details of events you sent a
> patch to improve documentation. Or any other patch -- code,
> documentation, tests -- any help will be greatly appreciated.
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

Re: [SQLObject] Saving a rol with a derivative atribute

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

On Wed, Sep 11, 2013 at 06:07:38PM +0400, Oleg Broytman <ph...@ph...> wrote:
> On Wed, Sep 11, 2013 at 10:25:31AM -0300, Georgio Barbosa <geo...@gm...> wrote:
> > I would like to know if it is possible to create a model class with a
> > default attribute derived from another.
> > 
> > An example:
> > 
> > class Post(SQLObject):
> > *title = StringCol()*
> > content = StringCol()
> > create_time = DateTimeCol(default=datetime.now)
> > tags = RelatedJoin('Tag')
> > author = ForeignKey('Author')
> > *slug = StringCol(default=title.replace(" ", "-"))*
> 
>    It is possible but in a rather complex non-obvious way. You have to
> use events (signals); unfortunately that gem of SQLObject is
> underdocumented (to say mildly), so you need to consult the code.
>    See http://sqlobject.org/SQLObject.html#events-signals for the
> starting point. Read events.py and lookup main.py to see how signals are
> sent and how SQLObject uses returned values.
>    You need to catch RowCreateSignal and RowUpdateSignal -- they are
> sent before INSERT and UPDATE correspondingly -- and update values to
> your need in your signal handlers.
> 
>    It would be great if after you learn the details of events you sent a
> patch to improve documentation. Or any other patch -- code,
> documentation, tests -- any help will be greatly appreciated.

   If you only need to set the default once you can override method
__init__ in your class, set the default and call parent's __init__. You
can also override .set() but simple assignment like

    row.title = new_value

doesn't call 'set(). If you want to catch all assignments events is the
only route.

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

Re: [SQLObject] Saving a rol with a derivative atribute

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

Hi!

On Wed, Sep 11, 2013 at 10:25:31AM -0300, Georgio Barbosa <geo...@gm...> wrote:
> I would like to know if it is possible to create a model class with a
> default attribute derived from another.
> 
> An example:
> 
> class Post(SQLObject):
> *title = StringCol()*
> content = StringCol()
> create_time = DateTimeCol(default=datetime.now)
> tags = RelatedJoin('Tag')
> author = ForeignKey('Author')
> *slug = StringCol(default=title.replace(" ", "-"))*

   It is possible but in a rather complex non-obvious way. You have to
use events (signals); unfortunately that gem of SQLObject is
underdocumented (to say mildly), so you need to consult the code.
   See http://sqlobject.org/SQLObject.html#events-signals for the
starting point. Read events.py and lookup main.py to see how signals are
sent and how SQLObject uses returned values.
   You need to catch RowCreateSignal and RowUpdateSignal -- they are
sent before INSERT and UPDATE correspondingly -- and update values to
your need in your signal handlers.

   It would be great if after you learn the details of events you sent a
patch to improve documentation. Or any other patch -- code,
documentation, tests -- any help will be greatly appreciated.

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

[SQLObject] Saving a rol with a derivative atribute

[Georgio B. <geo...@gm...>]

Hello all.

I would like to know if it is possible to create a model class with a
default attribute derived from another.

An example:

class Post(SQLObject):
*title = StringCol()*
content = StringCol()
create_time = DateTimeCol(default=datetime.now)
tags = RelatedJoin('Tag')
author = ForeignKey('Author')
*slug = StringCol(default=title.replace(" ", "-"))*


Thank you very much.

Re: [SQLObject] Question about how to create users using sqlobject

[Francisco C. <fra...@gm...>]

Thank you so much.


2013/9/2 Oleg Broytman <ph...@ph...>

> Hi!
>
> On Mon, Sep 02, 2013 at 03:40:51PM -0300, Francisco Chiotta <
> fra...@gm...> wrote:
> > Hello people,
> >                      I am new with sqlobject, I was seeing the package
> and
> > I think is a very good job.
>
>    Thank you!
>
> > I just have a question for you. There exist a
> > way to create users, of the database I am connected, or drop them using
> > sqlobject ? I am using sqlobject with postgres.
>
>    Alas, there is no aside from low-level SQL query like
> connection.query("CREATE USER name PASSWORD 'xxx'")
>
> > Sorry if the question is silly
>
>    It is not. Certainly there are many areas where SQLObject could be
> and should be improved. IWBN if sooner or later you join the effort.
>
> >  but I am a beginner in this
>
>    You are welcome!
>
> > and I didn't
> > find any information about it.
>
>    Documentation is one such area that needs a lot of improvements.
>
> > Thank you for your time.
> > Regards
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>

Re: [SQLObject] Question about how to create users using sqlobject

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

Hi!

On Mon, Sep 02, 2013 at 03:40:51PM -0300, Francisco Chiotta <fra...@gm...> wrote:
> Hello people,
>                      I am new with sqlobject, I was seeing the package and
> I think is a very good job.

   Thank you!

> I just have a question for you. There exist a
> way to create users, of the database I am connected, or drop them using
> sqlobject ? I am using sqlobject with postgres.

   Alas, there is no aside from low-level SQL query like
connection.query("CREATE USER name PASSWORD 'xxx'")

> Sorry if the question is silly

   It is not. Certainly there are many areas where SQLObject could be
and should be improved. IWBN if sooner or later you join the effort.

>  but I am a beginner in this

   You are welcome!

> and I didn't
> find any information about it.

   Documentation is one such area that needs a lot of improvements.

> Thank you for your time.
> Regards

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

[SQLObject] Question about how to create users using sqlobject

[Francisco C. <fra...@gm...>]

Hello people,
                     I am new with sqlobject, I was seeing the package and
I think is a very good job. I just have a question for you. There exist a
way to create users, of the database I am connected, or drop them using
sqlobject ? I am using sqlobject with postgres.

Sorry if the question is silly, but I am a beginner in this, and I didn't
find any information about it.

Thank you for your time.
Regards

[SQLObject] SQLObject 1.5.0rc1

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

Hello!

I'm pleased to announce version 1.5.0rc1, the first release candidate
of the upcoming release of branch 1.5 of SQLObject.


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

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

* Helpers for class Outer were changed to lookup columns in table's
  declarations.

* Support for Python 2.4 is declared obsolete and will be removed
  in the next release.

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

* Encode unicode enum values to str.

* Removed setDeprecationLevel from the list of public functions.

* A number of fixes for tests.

Bugfixes
--------

* A bug was fixed in DBConnection.close(); close() doesn't raise
  an UnboundLocalError if connection pool is empty.

* Fixed parameters for pymssql.


Contributors for this release are Patrick Gendron, Rhubarb Sin,
Neil Muller, Robert Ayrapetyan and Gert Burger.


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.5.0rc1dev-r4659

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] Possible bug in EnumCol/EnumValidator

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

On Thu, Aug 08, 2013 at 01:47:42PM +0400, Oleg Broytman <ph...@ph...> wrote:
> On Thu, Aug 08, 2013 at 09:34:18AM +0200, Gert Burger <ger...@gm...> wrote:
> > Oleg Broytman wrote, On 07/08/2013 19:51:
> > > On Wed, Aug 07, 2013 at 11:52:15AM +0200, Gert Burger <ger...@gm...> wrote:
> > >> Attached is a test case demonstrating the issue. Tested with version
> > >> 1.5.0b1 and some previous versions.
> > > 
> > >    Thanks for the report!
> > > 
> > >> The EnumValidator checks if the value given is in the list of valid
> > >> enumValues but this allows unicode values to match normal string values.
> > >>
> > >> That allows unicode objects into the SQL generation code which forces
> > >> python to create unicode strings instead of normal strings. This means
> > >> already encoded values will be decoded again and probably with the wrong
> > >> encoding.
> > >>
> > >> My guess is that the EnumValidator should return only str objects that
> > >> are properly encoded.
> > > 
> > >    At the first glance I'm not sure what should be the correct behaviour
> > > for EnumValidator. I'll think about it.
> > 
> > I'm also unsure hoe EnumValidator should react but I'm pretty sure that
> > one needs to either cater for unicode strings in final SQL generation or
> > prevent them from reaching that stage and I assume the Validators are
> > responsible for encoding.
> 
>    Now I think you are right. EnumValidator should convert unicode
> values to strings because that how SQLObject currently works -- it uses
> str internally and is at most unicode-aware.
>    So my plan is to move method getDbEncoding from SOUnicodeCol to SOCol
> and use it everywhere validators need the encoding. The change is rather
> big so I will only apply it (if the approach will work at all) to
> branches 1.5 and the trunk.

   Done. getDbEncoding moved to SOCol at the revision 4650,
EnumValidator converts unicode values to str at 4651 (branch 1.5),
merged into the trunk at 4653.
   Please test and report.

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

Re: [SQLObject] possible bug in pymssql make_conn_str

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

On Mon, Aug 19, 2013 at 07:23:53PM -0700, Robert Ayrapetyan <rob...@gm...> wrote:
> Unexpectedly it started to use adodbapi driver by default
> (previously it somehow was pymssql),
> after passing driver="pymssql" to "connectionForURI" things started
> to work as expected.
> 
> On Mon Aug 19 05:24:39 2013, Oleg Broytman wrote:
> >On Sat, Aug 17, 2013 at 12:02:52AM +0400, Oleg Broytman <ph...@ph...> wrote:
> >>    I changed the generation of parameters for pymssql. Committed in the
> >>revisions 4644, 4645 in branch 1.5 (code and news), 4646 in the trunk.
> >>    Can you test the patch? Or do you want me to roll out a beta release?
> >
> >    Minor update at revisions 4647, 4648.

   Thank you for the report!

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

Re: [SQLObject] possible bug in pymssql make_conn_str

[Robert A. <rob...@gm...>]

Unexpectedly it started to use adodbapi driver by default (previously 
it somehow was pymssql),
after passing driver="pymssql" to "connectionForURI" things started to 
work as expected.

On Mon Aug 19 05:24:39 2013, Oleg Broytman wrote:
> On Sat, Aug 17, 2013 at 12:02:52AM +0400, Oleg Broytman <ph...@ph...> wrote:
>>     I changed the generation of parameters for pymssql. Committed in the
>> revisions 4644, 4645 in branch 1.5 (code and news), 4646 in the trunk.
>>     Can you test the patch? Or do you want me to roll out a beta release?
>
>     Minor update at revisions 4647, 4648.
>
> Oleg.

Re: [SQLObject] possible bug in pymssql make_conn_str

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

On Sat, Aug 17, 2013 at 12:02:52AM +0400, Oleg Broytman <ph...@ph...> wrote:
>    I changed the generation of parameters for pymssql. Committed in the
> revisions 4644, 4645 in branch 1.5 (code and news), 4646 in the trunk.
>    Can you test the patch? Or do you want me to roll out a beta release?

   Minor update at revisions 4647, 4648.

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

Re: [SQLObject] possible bug in pymssql make_conn_str

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

Hi! Please avoid top-posting. You know the problem:

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

   My answer is below.

On Fri, Aug 16, 2013 at 11:19:35AM -0700, Robert Ayrapetyan <rob...@gm...> wrote:
> Not getting own emails and replies (all mailing list settings are set 
> by default,
> however I found a reply in a mail archive here:
> http://sourceforge.net/mailarchive/forum.php?forum_name=sqlobject-discuss&max_rows=25&style=nested&viewmonth=201308).
> 
> Anyway, instead of
> 
> [".", keys.user, keys.password, keys.db, 0, 60, None, False, keys.host, 
> None, keys.port]
> 
> for
> 
> def connect(server='.', user='', password='', database='', timeout=0,
>           login_timeout=60, charset=None, as_dict=False,
>           host='', appname=None, port='1433')
> 
> (which works fine for me)
> 
> it would be better to pass only user, password, database, host and port 
> (if set explicitly)
> (leaving default vals for other params).
> I'm not a python guru and have no idea how to implement this via 
> dynamically generated list of params (similarly to how it was).

   I changed the generation of parameters for pymssql. Committed in the
revisions 4644, 4645 in branch 1.5 (code and news), 4646 in the trunk.
   Can you test the patch? Or do you want me to roll out a beta release?

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

Re: [SQLObject] possible bug in pymssql make_conn_str

[Robert A. <rob...@gm...>]

Not getting own emails and replies (all mailing list settings are set 
by default,
however I found a reply in a mail archive here:
http://sourceforge.net/mailarchive/forum.php?forum_name=sqlobject-discuss&max_rows=25&style=nested&viewmonth=201308).

Anyway, instead of

[".", keys.user, keys.password, keys.db, 0, 60, None, False, keys.host, 
None, keys.port]

for

def connect(server='.', user='', password='', database='', timeout=0,
          login_timeout=60, charset=None, as_dict=False,
          host='', appname=None, port='1433')

(which works fine for me)

it would be better to pass only user, password, database, host and port 
(if set explicitly)
(leaving default vals for other params).
I'm not a python guru and have no idea how to implement this via 
dynamically generated list of params (similarly to how it was).


On Thu Aug 15 17:57:37 2013, Robert Ayrapetyan wrote:
> Hello.
>
> There is a code in sqlobject/mssql/mssqlconnection.py:
>
> else: # pymssql
>             self.dbconnection = sqlmodule.connect
>             sqlmodule.Binary = lambda st: str(st)
>             # don't know whether pymssql uses unicode
>             self.usingUnicodeStrings = False
>             self.make_conn_str = lambda keys:  \
>                    ["", keys.user, keys.password, keys.host, keys.db]
>
> However, pymssql.connect declaration is following:
>
> def connect(server='.', user='', password='', database='', timeout=0,
>          login_timeout=60, charset=None, as_dict=False,
>          host='', appname=None, port='1433')
>
> So seems make_conn_str produces wrong set of params which throws:
>
> pymssql.InterfaceError: Connection to the database failed for an
> unknown reason.
>
> (because actual host value is empty).
>
> I've updated it like that:
>
> self.make_conn_str = lambda keys:  \
>                    [".", keys.user, keys.password, keys.db, 0, 60,
> None, False, keys.host, None, keys.port]
>
> and things started to work.
>
> Thanks.

Re: [SQLObject] possible bug in pymssql make_conn_str

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

On Thu, Aug 15, 2013 at 05:57:37PM -0700, Robert Ayrapetyan <rob...@gm...> wrote:
> There is a code in sqlobject/mssql/mssqlconnection.py:
> 
> else: # pymssql
>              self.dbconnection = sqlmodule.connect
>              sqlmodule.Binary = lambda st: str(st)
>              # don't know whether pymssql uses unicode
>              self.usingUnicodeStrings = False
>              self.make_conn_str = lambda keys:  \
>                     ["", keys.user, keys.password, keys.host, keys.db]
> 
> However, pymssql.connect declaration is following:
> 
> def connect(server='.', user='', password='', database='', timeout=0,
>           login_timeout=60, charset=None, as_dict=False,
>           host='', appname=None, port='1433')
> 
> So seems make_conn_str produces wrong set of params which throws:
> 
> pymssql.InterfaceError: Connection to the database failed for an unknown 
> reason.
> 
> (because actual host value is empty).
> 
> I've updated it like that:
> 
> self.make_conn_str = lambda keys:  \
>                     [".", keys.user, keys.password, keys.db, 0, 60, 
> None, False, keys.host, None, keys.port]
> 
> and things started to work.

   Thank you. I don't use MSSQL so I cannot test it. I will apply and
commit your code later.

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

[SQLObject] possible bug in pymssql make_conn_str

[Robert A. <rob...@gm...>]

Hello.

There is a code in sqlobject/mssql/mssqlconnection.py:

else: # pymssql
             self.dbconnection = sqlmodule.connect
             sqlmodule.Binary = lambda st: str(st)
             # don't know whether pymssql uses unicode
             self.usingUnicodeStrings = False
             self.make_conn_str = lambda keys:  \
                    ["", keys.user, keys.password, keys.host, keys.db]

However, pymssql.connect declaration is following:

def connect(server='.', user='', password='', database='', timeout=0,
          login_timeout=60, charset=None, as_dict=False,
          host='', appname=None, port='1433')

So seems make_conn_str produces wrong set of params which throws:

pymssql.InterfaceError: Connection to the database failed for an unknown 
reason.

(because actual host value is empty).

I've updated it like that:

self.make_conn_str = lambda keys:  \
                    [".", keys.user, keys.password, keys.db, 0, 60, 
None, False, keys.host, None, keys.port]

and things started to work.

Thanks.

Re: [SQLObject] Possible bug in EnumCol/EnumValidator

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

On Thu, Aug 08, 2013 at 09:34:18AM +0200, Gert Burger <ger...@gm...> wrote:
> Oleg Broytman wrote, On 07/08/2013 19:51:
> > On Wed, Aug 07, 2013 at 11:52:15AM +0200, Gert Burger <ger...@gm...> wrote:
> >> Attached is a test case demonstrating the issue. Tested with version
> >> 1.5.0b1 and some previous versions.
> > 
> >    Thanks for the report!
> > 
> >> The EnumValidator checks if the value given is in the list of valid
> >> enumValues but this allows unicode values to match normal string values.
> >>
> >> That allows unicode objects into the SQL generation code which forces
> >> python to create unicode strings instead of normal strings. This means
> >> already encoded values will be decoded again and probably with the wrong
> >> encoding.
> >>
> >> My guess is that the EnumValidator should return only str objects that
> >> are properly encoded.
> > 
> >    At the first glance I'm not sure what should be the correct behaviour
> > for EnumValidator. I'll think about it.
> 
> I'm also unsure hoe EnumValidator should react but I'm pretty sure that
> one needs to either cater for unicode strings in final SQL generation or
> prevent them from reaching that stage and I assume the Validators are
> responsible for encoding.

   Now I think you are right. EnumValidator should convert unicode
values to strings because that how SQLObject currently works -- it uses
str internally and is at most unicode-aware.
   So my plan is to move method getDbEncoding from SOUnicodeCol to SOCol
and use it everywhere validators need the encoding. The change is rather
big so I will only apply it (if the approach will work at all) to
branches 1.5 and the trunk.

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

Re: [SQLObject] Possible bug in EnumCol/EnumValidator

[Gert B. <ger...@gm...>]

Oleg Broytman wrote, On 07/08/2013 19:51:
> Hi!
> 
> On Wed, Aug 07, 2013 at 11:52:15AM +0200, Gert Burger <ger...@gm...> wrote:
>> Attached is a test case demonstrating the issue. Tested with version
>> 1.5.0b1 and some previous versions.
> 
>    Thanks for the report!
> 
>> The EnumValidator checks if the value given is in the list of valid
>> enumValues but this allows unicode values to match normal string values.
>>
>> That allows unicode objects into the SQL generation code which forces
>> python to create unicode strings instead of normal strings. This means
>> already encoded values will be decoded again and probably with the wrong
>> encoding.
>>
>> My guess is that the EnumValidator should return only str objects that
>> are properly encoded.
> 
>    At the first glance I'm not sure what should be the correct behaviour
> for EnumValidator. I'll think about it.
> 
> Oleg.
> 

I'm also unsure hoe EnumValidator should react but I'm pretty sure that
one needs to either cater for unicode strings in final SQL generation or
prevent them from reaching that stage and I assume the Validators are
responsible for encoding.

The situation in Py3 will be different for sure.

-- 
Regards
Gert Burger

Re: [SQLObject] Possible bug in EnumCol/EnumValidator

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

Hi!

On Wed, Aug 07, 2013 at 11:52:15AM +0200, Gert Burger <ger...@gm...> wrote:
> Attached is a test case demonstrating the issue. Tested with version
> 1.5.0b1 and some previous versions.

   Thanks for the report!

> The EnumValidator checks if the value given is in the list of valid
> enumValues but this allows unicode values to match normal string values.
> 
> That allows unicode objects into the SQL generation code which forces
> python to create unicode strings instead of normal strings. This means
> already encoded values will be decoded again and probably with the wrong
> encoding.
> 
> My guess is that the EnumValidator should return only str objects that
> are properly encoded.

   At the first glance I'm not sure what should be the correct behaviour
for EnumValidator. I'll think about it.

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

[SQLObject] Possible bug in EnumCol/EnumValidator

[Gert B. <ger...@gm...>]

Hi

Attached is a test case demonstrating the issue. Tested with version
1.5.0b1 and some previous versions.

The EnumValidator checks if the value given is in the list of valid
enumValues but this allows unicode values to match normal string values.

That allows unicode objects into the SQL generation code which forces
python to create unicode strings instead of normal strings. This means
already encoded values will be decoded again and probably with the wrong
encoding.

My guess is that the EnumValidator should return only str objects that
are properly encoded.

Regards
Gert Burger

Re: [SQLObject] SQLObject.q.foreign_keyID vs. SQLObject.q.foreign_key_ID

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

On Fri, Aug 02, 2013 at 11:43:59AM -0400, Rhubarb Sin <rhu...@gm...> wrote:
> I changed all instances of _ID to ID in my code to test with SQLObject
> 1.5.0b1dev-r4622 and found no problems.

   Thank you for the inspiration and the report!

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

Re: [SQLObject] SQLObject.q.foreign_keyID vs. SQLObject.q.foreign_key_ID

[Rhubarb S. <rhu...@gm...>]

On 7/20/13, Oleg Broytman <ph...@ph...> wrote:
> On Thu, Jul 11, 2013 at 09:45:13AM -0400, Rhubarb Sin <rhu...@gm...>
> wrote:
>> On 7/10/13, Oleg Broytman <ph...@ph...> wrote:
>> >    I tested this, it works, so I committed the change at the revision
>> > 4613:
>> > http://sourceforge.net/mailarchive/forum.php?thread_name=E1Uwysp-0003DP-4G%40webwareforpython.org&forum_name=sqlobject-cvs
>> >
>> >    This is a major API change IMO so I'm cautious and only committed to
>> > the trunk.
>> >    Do you want me to release a beta version so you can test it with
>> > your
>> > code?
>>
>> Yes, please do so, and I'll report my results.
>
>    Done. Waiting for a report.

I changed all instances of _ID to ID in my code to test with SQLObject
1.5.0b1dev-r4622 and found no problems.