On 12/14/2015 03:08 AM, Michal Petrucha wrote:
> On Thu, Dec 10, 2015 at 12:31:33PM -0500, Mike Bayer wrote:
>>
>>
>> On 12/10/2015 10:21 AM, Michal Petrucha wrote:
>>> Hello alchemists,
>>>
>>> There's something that's been bugging me for a while now. I
>>> even asked about it on [stackoverflow][1], but it didn't get
>>> much attention there. It's been suggested to me on IRC that
>>> this mailing list might be a better place for this question.
>>>
>>> When you take a look at the [table_per_relation ORM
>>> example][2], you can see that the argument passed to
>>> `ForeignKey` [here][3] is the “raw” “tablename.column”.
>>> However, since the entire point of declarative is to use
>>> higher-level constructs to abstract away some of the
>>> lower-level SQL details, it would make sense to me to use
>>> `cls.id` here instead. (I want this here declarative field to
>>> point to this other declarative field, instead of saying, I
>>> want this declarative field to point to this SQL column of that
>>> SQL table.)
>>
>> the first thing I don't understand is that the code you refer to
>> is locating the correct name dynamically. So why does it matter?
>> You aren't typing in the name of the table or class yourself.
>
> Why does it matter? Let's say it's a matter of personal taste and
> consistency -- I like to use the ForeignKey(OtherClass.id) API
> rather than ForeignKey('other_table.id'), and I like to be
> consistent about which APIs I use.
The SQLAlchemy ORM is built on top of the Core and using it involves
constant use of both APIs, and in fact up until version 0.4 or so, all
ORM queries were still done in terms of Core Table objects, e.g.
session.query(User).filter(user_table.c.foo == 'bar'). Classical
mappings again involve use of the mapper() function which merges a
class to Core table constructs.
In this case, allowing an ORM concept like OtherClass.id into
ForeignKey() is in fact the less consistent approach, because
ForeignKey is part of Core. But around 0.8 or so we added special
hooks that allow ForeignKey and others to interpret ORM elements like
OtherClass.id while still maintaining total ignorance anything ORM,
not even a monkeypatch.
But in any case, this is a mapping recipe and there's absolutely no
lack of purity or consistency by using a Core concept inside of the
already-Core ForeignKey object, this recipe is part of the
configuration of an object relational mapping which explicitly means,
"we are taking our classes and mapping them to relational Core
constructs".
>
> Not to mention that in this particular example, typing
> ForeignKey(cls.id) would be a lot shorter and require less
> brainpower to parse than ForeignKey("%s.id" % cls.__tablename__).
>
>> Second thing is, you can pass the class-bound column to the
>> ForeignKey, sure, just as an object, not a string:
>>
>> ForeignKey(WhateverClass.id)
>>
>> it just requires that you have WhateverClass already available.
>
> Exactly -- and the point of my question was that this apparently
> doesn't work in that example; I assume it is because the class is
> not fully initialized at that point, and I'm wondering if there's
> anything that can be done about it.
>
> Cheers, Michal
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
