Michael,
thank you very much for your quick effort. Much appreciated. Especially
after I was close to biting my keyboard after four hours of frustration
(both over the strange error message and the fact that these two
database tables had no better way to work together).
On Mon, Jun 18, 2007 at 05:17:33PM -0400, Michael Bayer wrote:
> also, this works:
>
> mapper(DhcpHost, dhcp_hosts_table)
>
> mapper(DnsRecord, powerdns_records_table,
> properties={
> 'dhcphost': relation(DhcpHost,
> primaryjoin=(cast
> (powerdns_records_table.c.content,PGInet)
> ==dhcp_hosts_table.c.ip_address),
> foreign_keys=[powerdns_records_table.c.content],
> remote_side=[dhcp_hosts_table.c.ip_address],
> viewonly=True,
> ),
> }
> )
Yes, this works well. Even updating the DHCP table through the
'dhcphost' property works perfectly when flushing the session. Funny -
especially since viewonly is set. Is it because it's a one-to-one
relation and I am just updating existing rows? This is my log from the
flushing:
BEGIN
UPDATE dhcp_hosts SET hostname=%(hostname)s WHERE dhcp_hosts.id =
%(dhcp_hosts_id)s
{'hostname': 'chaasdhcp', 'dhcp_hosts_id': 859}
COMMIT
> in the case of CAST specifically, we do have some awareness that we
> need to go from PGInet -> string when setting DhcpHost's "content"
> attribute...but i dont like to redefine DB functionality on the
> Python side since we cant easily generalize it.
Going to string might not be the best idea anyway because PGInet is more
versatile. You can use << and >> operators in PostgreSQL that lets you
compare networks or check if one network/IP is contained within another.
You can't do that with strings. An explicit cast doesn't hurt here.
> ive added some comments to this effect to the ticket. this feature
> would be better in the 0.4 series, which has several weeks before
> release though is available via SVN. does that work for you ?
Perfectly. Although all the hassle makes me think even harder if there
is really no other way of connecting these two database tables. A casted
join with string comparison gets dirtier every time I look at it. :(
I must really say that SQLAlchemy is an impressive piece of software.
I am always proven wrong when I assume that SQLAlchemy is not powerful
enough to do certain complicated tasks. Thanks for proving me wrong time
and again. :)
Thanks again.
Christoph
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
