Thread: [SQLObject] Final patch for 0.4 with unit tests
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
Menu
▾
▴
sqlobject-discuss
|
From: G. <fra...@cl...> - 2003-07-01 15:01:11
Attachments:
so04-2.diff
|
Hello,
I've made some tests around the features I added.
While testing, I had to add another change : cause of alphanum ID, table cr=
eation was wrong and insert failed.
So, that must be specified in the class with _idAlpha and _idLength attribu=
te.
Same for relation : joinFieldAlpha and otherFieldAlpha are used to specify =
this. I *know* that field size is missing, so intermediate table generation=
has hard-coded field size (16 caracter yet).
But, as Ian says that relation object design will move in 0.5, I haven't tr=
ied to specify size by another attribute (joinFieldLength and otherFieldLen=
gth by example) because *I* don't need to generate table at runtime (the da=
tabase is already generated when I launch my client)
class Pet(SQLObject):
_idAlpha =3D True
_idLength =3D 16
code =3D StringCol()
name =3D StringCol()
favoriteToyID =3D IntCol(foreignKey=3D'Toy')
_joins =3D [RelatedJoin('Toy', joinField=3D'code', joinFieldAlpha=3DTru=
e, joinColumn=3D'pet_code', otherColumn=3D'toy_code', otherField=3D'alphaCo=
de', otherFieldAlpha=3DTrue, intermediateTable=3D'pet_toy')]
class Toy(SQLObject):
alphaCode =3D StringCol(alternateID=3DTrue)
name =3D StringCol()
Note again that it works for *postgres only*
Fran=E7ois
|
|
From: Matt G. <ma...@po...> - 2003-07-01 15:56:14
|
This is just a quick thought, and probably something for a later
release, but couldn't an alphanumeric id be expressed something like
this:
class Pet(SQLObject):
id =3D IdCol(type=3D'alpha', length=3D32)
code =3D StringCol()
name =3D StringCol()
toyID =3D IntCol(foreignKey=3D'Toy')
_joins =3D [...]
class Toy(SQLObject):
name =3D StringCol()
Note that Toy does not specify the id attribute and so uses the
automatically generated version, as currently implemented.
Sorry if I am repeating things that have already been discussed, I have
not been following the SQLObject mailing list properly until recently.
Cheers, Matt
On Tue, 2003-07-01 at 15:54, Fran=E7ois Girault wrote:
> Hello,
>=20
> I've made some tests around the features I added.
>=20
> While testing, I had to add another change : cause of alphanum ID, table =
creation was wrong and insert failed.
>=20
> So, that must be specified in the class with _idAlpha and _idLength attri=
bute.
>=20
> Same for relation : joinFieldAlpha and otherFieldAlpha are used to specif=
y this. I *know* that field size is missing, so intermediate table generati=
on has hard-coded field size (16 caracter yet).
>=20
> But, as Ian says that relation object design will move in 0.5, I haven't =
tried to specify size by another attribute (joinFieldLength and otherFieldL=
ength by example) because *I* don't need to generate table at runtime (the =
database is already generated when I launch my client)
>=20
> class Pet(SQLObject):
> _idAlpha =3D True
> _idLength =3D 16
> code =3D StringCol()
> name =3D StringCol()
> favoriteToyID =3D IntCol(foreignKey=3D'Toy')
> _joins =3D [RelatedJoin('Toy', joinField=3D'code', joinFieldAlpha=3DT=
rue, joinColumn=3D'pet_code', otherColumn=3D'toy_code', otherField=3D'alpha=
Code', otherFieldAlpha=3DTrue, intermediateTable=3D'pet_toy')]
>=20
> class Toy(SQLObject):
> alphaCode =3D StringCol(alternateID=3DTrue)
> name =3D StringCol()
>=20
>=20
> Note again that it works for *postgres only*
>=20
> Fran=E7ois
--=20
Matt Goodall, Pollenation Internet Ltd
w: http://www.pollenation.net
e: ma...@po...
|
|
From: Matt G. <ma...@po...> - 2003-07-01 20:01:58
|
Sorry about the repeated messages, I really did only send it once. - Matt |
|
From: Ian B. <ia...@co...> - 2003-07-01 20:15:24
|
On Tue, 2003-07-01 at 10:56, Matt Goodall wrote:
> This is just a quick thought, and probably something for a later
> release, but couldn't an alphanumeric id be expressed something like
> this:
>
> class Pet(SQLObject):
> id = IdCol(type='alpha', length=32)
> code = StringCol()
> name = StringCol()
> toyID = IntCol(foreignKey='Toy')
> _joins = [...]
Yes, I think this is better. Or rather:
class Pet(SQLObject):
id = StringCol(length=32)
That it's named "id" would imply its role. You could then use a dbName
argument in lieu of _idName.
Ian
|
|
From: G. <fra...@cl...> - 2003-07-02 07:53:10
|
>=20 > class Pet(SQLObject): > id =3D IdCol(type=3D'alpha', length=3D32) > code =3D StringCol() > name =3D StringCol() > toyID =3D IntCol(foreignKey=3D'Toy') > _joins =3D [...] >=20 I find this way rather elegant. I'll implement in few days if I have time t= o, but I wasn't planning to add classes to the project, like IdCol, just tu= ning it to my needs. But that's a pretty good suggestion, thanks. Fran=E7ois |
|
From: Matt G. <ma...@po...> - 2003-07-01 16:01:43
|
On Tue, 2003-07-01 at 15:54, Fran=E7ois Girault wrote: > But, as Ian says that relation object design will move in 0.5 <snip> Ian, is there anything documenting your plans for relations? I scanned the recent mailing list archives but did not see anything obvious. Thanks, Matt --=20 Matt Goodall, Pollenation Internet Ltd w: http://www.pollenation.net e: ma...@po... |
|
From: Ian B. <ia...@co...> - 2003-07-01 20:53:45
|
On Tue, 2003-07-01 at 11:01, Matt Goodall wrote: > On Tue, 2003-07-01 at 15:54, Fran=E7ois Girault wrote: >=20 > > But, as Ian says that relation object design will move in 0.5 <snip> >=20 > Ian, is there anything documenting your plans for relations? I scanned > the recent mailing list archives but did not see anything obvious. Specifically joins. Right now joins return lists of objects. Instead I want them to return something more like SelectResult -- an iterable object that also has methods for adding new objects, removing, etc.=20 (Probably it will actually be a subclass of SelectResult, as SelectResult's methods would apply as well) Ian |
Thanks for helping keep SourceForge clean.
X