On 08/20/2016 08:27 PM, Tom Kedem wrote:
I suppose I could have a discriminator value for "function type", but I
have no use for it now (so yeah, the base class is a single column one).

It's a simplified model. The real use-case is as such - the base class
is "function" and the inheriting classes are all sorts of functions (all
concrete classes). They all have a collection of "arguments" (many to
many), which I define in the base class - since the "arguments" can only
point to a single table.

Maybe it's not the best mapping, I'm open for suggestions. But is there
anything wrong in my configuration or understanding?

Two things do not make sense, in terms of the use of ConcreteBase and "concrete=True".

One is:


    id = Column(Integer, ForeignKey(User.id), primary_key=True)

on SuperUser.

The other is:

class UserKeyword(Base):
    __tablename__ = 'user_keyword'
    user_id = Column(Integer, ForeignKey('user.id'), primary_key=True)


both of these imply that the fields of a SuperUser object are stored in the "super_user" table *and* the "user" table.

Also, when you say "I suppose I could have a discriminator..." in response to the question, "did you mean for this to be joined inheritance?", that suggests you might be under the impression that "don't have a discriminator" means you must use "concrete inheritance", which is not true. A "discriminator" is not necessary for any style of inheritance, as long as you don't need to load objects polymorphically.

Same question as before, more specifically. When you load a row from "super_user" in order to get a SuperUser object, should the ORM also be loading a row from "user" that matches up to it? Or can you get every possible field in a SuperUser from the "super_user" table alone without ever looking at "user"? If the former, that would be joined inheritance. that's what this looks like.










On Saturday, August 20, 2016 at 10:44:24 PM UTC+3, Mike Bayer wrote:

    This doesn't look like a concrete mapping, you have a foreign key
    from SuperUser to User.   Are you sure this isn't supposed to be an
    ordinary joined inheritance model ?

    On Saturday, August 20, 2016, Tom Kedem <tomk...@gmail.com
    <javascript:>> wrote:

        I have the following setup (attached python file).
        I'm using an inheritance hierarchy without a discriminator
        field, deriving from AbstractBase.
        I want to be able to use the "keywords" attribute in the
        "SuperUser" class, and from the documentation I understand I
        need to redefine it, however that doesn't seem to work.
        I assume I could manually use a primary join there (as the error
        indicates), but as I understand that's exactly what
        "AbstractBase" class should handle...

        --
        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
        <https://groups.google.com/group/sqlalchemy>.
        For more options, visit https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>.

--
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
<mailto:sqlalchemy+unsubscr...@googlegroups.com>.
To post to this group, send email to sqlalchemy@googlegroups.com
<mailto:sqlalchemy@googlegroups.com>.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.

--
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.

Reply via email to