On Mon, Dec 11, 2006 at 11:11:51PM +, Paul Johnston wrote:
> SQL Server 2005 does support
> identifiers with unicode characters
Alas, SQLObject is not fully unicode-aware yet. (And, BTW, unicode
*names* (not values) is a big surprise for me.)
> However, I guess it would
> be a big job to
Hi,
Ok, I've looked into this a bit more and the value is unicode because it
is returned from columnsFromSchema in mssqlconnection. Changing line 216
from
kw['name'] = soClass.sqlmeta.style.dbColumnToPythonAttr(field)
to
kw['name'] =
str(soClass.sqlmeta.style.dbColumnToP
On Mon, Dec 11, 2006 at 04:16:23PM -0500, David Turner wrote:
> >Because accessing the DB during row creation when the "row" is actually
> > a set of rows exposes the inconsistent state of the DB, and SQLObject
> > certainly cannot prevent this.
>
> Sure it can -- using transactions in the way
On Mon, 2006-12-11 at 23:52 +0300, Oleg Broytmann wrote:
> On Mon, Dec 11, 2006 at 03:37:38PM -0500, David Turner wrote:
> > >Shouldn't it be considered a bug in the user program if it access the
> > > DB
> > > during row creation?
> >
> > I don't see why it should be.
>
>Because accessi
On Mon, Dec 11, 2006 at 03:37:38PM -0500, David Turner wrote:
> >Shouldn't it be considered a bug in the user program if it access the DB
> > during row creation?
>
> I don't see why it should be.
Because accessing the DB during row creation when the "row" is actually
a set of rows exposes
On Mon, 2006-12-11 at 23:02 +0300, Oleg Broytmann wrote:
> On Mon, Dec 11, 2006 at 02:57:03PM -0500, David Turner wrote:
> > This is not quite true, if I understand correctly. First, sqlobject
> > creates the base row, then (if necessary) it calls methods to get
> > default values for the derived
On Mon, Dec 11, 2006 at 02:57:03PM -0500, David Turner wrote:
> This is not quite true, if I understand correctly. First, sqlobject
> creates the base row, then (if necessary) it calls methods to get
> default values for the derived class, then it creates the derived row.
> So the user's program d
On Mon, 2006-12-11 at 22:53 +0300, Oleg Broytmann wrote:
> On Mon, Dec 11, 2006 at 02:47:05PM -0500, David Turner wrote:
> > There's a bit of a tricky thing about transactions: we need to make sure
> > that the calculation of default values for the derived row takes place
> > outside (but simultane
On Mon, Dec 11, 2006 at 02:47:05PM -0500, David Turner wrote:
> There's a bit of a tricky thing about transactions: we need to make sure
> that the calculation of default values for the derived row takes place
> outside (but simultaneous with) the transaction, because anything inside
> the transact
On Mon, 2006-12-11 at 22:24 +0300, Oleg Broytmann wrote:
> On Mon, Dec 11, 2006 at 02:17:20PM -0500, David Turner wrote:
> > 1. Wait to create the row in base until just before the row in derived
> > is to be created.
> >
> > 2. (maybe) use transactions.
>
>We cannot wait because we need an i
On Mon, Dec 11, 2006 at 02:17:20PM -0500, David Turner wrote:
> 1. Wait to create the row in base until just before the row in derived
> is to be created.
>
> 2. (maybe) use transactions.
We cannot wait because we need an id from the parent table to insert a
new row to the child table with the
Consider the following code:
from sqlobject import *
from sqlobject.inheritance import InheritableSQLObject
__connection__ = "sqlite:/:memory:"
def default_morx():
deriveds = list(Derived.select())
if deriveds.count():
return deriveds[0].morx
else:
return -1
class Ba
On Mon, Dec 11, 2006 at 05:46:11PM +, Paul Johnston wrote:
> I've just submitted a patch (request ID 1613369) with a simple bug fix
> that means "tg-admin sql status" now works for me. I am using the MSSQL
> backend.
The patch is incorrect. First, where from sqlIdentifier() got unicode?
S
Hi,
I've just submitted a patch (request ID 1613369) with a simple bug fix
that means "tg-admin sql status" now works for me. I am using the MSSQL
backend.
Any questions, just drop me a line.
Paul
-
Take Surveys. Earn Cas
[I'm not subscribed; please CC me on replies]
Code:
from sqlobject import *
from sqlobject.inheritance import InheritableSQLObject
__connection__ = "sqlite:/:memory:?debug=t"
class Role(InheritableSQLObject):
department = StringCol()
persons = RelatedJoin("Person")
class Student(Role):
Hi,
I did some work on writing an InformixDB backend for SQLObject. This was so
i could eval TurboGears for an in-house project. In the end TG didn't meet
the criteria so my Informix adaptor didn't get to the point of passing all
the SQLObject unit tests. I was contacted by Carsten Haese the main
On Mon, Dec 11, 2006 at 10:55:51AM +0100, Hans Murx wrote:
> in the sqlobject-discuss archives I found, that there was work on adding
> support for informixDB to SQLObject about a year ago. As far as I can see,
> informixDB is not yet supported. :-(
>
> Can anybody tell me about the status of this
Hi,
in the sqlobject-discuss archives I found, that there was work on adding
support for informixDB to SQLObject about a year ago. As far as I can see,
informixDB is not yet supported. :-(
Can anybody tell me about the status of this project?
Thank you,
Heinz
-
Luke: this would be the obvious solution if it did work (this actually
was the first thing I tried), alas no go, at least on 0.7.0 and 0.7.1.
Oleg: this gives you no control over actual table names. I forgot to
mention this is a must as well, we have tables from an external source
(exported from
19 matches
Mail list logo
