LanX has asked for the wisdom of the Perl Monks concerning the following question:

Hi

My understanding of Object-relational mapping (ORM) is what I first encountered with Ruby on Rails ("Active Records").

A way to represent a data model in OOP where every table is a class, and every row an object of that class.

While very consistent on it's own, it's limiting the "relational" possibilities of SQL and is hard to integrate into an already existing non-ORM schema.

(edit: These problems are known as Object–relational impedance mismatch )

And I've always been under the impression that DBIx::Class doesn't have these limitations to restrict the possibilities of SQL.

Now a colleague is insisting that it is indeed an ORM because the CPAN-module says so

NAME

DBIx::Class - Extensible and flexible object <-> relational mapper.

Please enlighten me about the right use of terminology. :)

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery

Replies are listed 'Best First'.
Re: Terminology: Is DBIx::Class an ORM?
by Arunbear (Prior) on Jun 02, 2021 at 22:22 UTC
      > I'd say it is an ORM, but ORM can refer to different architectural flavours,

      Many thanks, that explains a lot. :)

      > DBIx::Class::ResultSet

      I'd rather call this an SQL abstraction.

      It's much like SQL::Abstract and allows to cover (almost?) all semantics of SQL queries.

      But yeah, like I said I'm strongly associating ORM to "Active Records" and the resulting limitations.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

        And where do you draw the line between ORM and SQL abstraction?
Re: Terminology: Is DBIx::Class an ORM?
by haukex (Bishop) on Jun 02, 2021 at 15:27 UTC

    I've always thought that since DBIx::Class Maps an Object-oritented data structure to a Relational database, it's an ORM :-) Another way of looking at it, if I want to persist my OO classes to disk, an ORM is one way of doing that. In a quick skim of Object–relational impedance mismatch, it seems to mostly describe issues that would affect code that accesses the same database both via an ORM and without an ORM - that can indeed be a giant pain. But in regards to your question, I'd ask the other way around: why wouldn't DBIx::Class be an ORM?

      I've always thought that since DBIx::Class Maps an Object-oritented data structure to a Relational database, it's an ORM :-)

      Uh-oh... I always found it easy to map an existing relational database to DBIx::Class objects using the DBIx::Class::Schema::Loader and, also often cumbersome to map my object structures to a RDBMS if it wasn't designed for a relational database in the first place.

        often cumbersome to map my object structures to a RDBMS if it wasn't designed for a relational database in the first place

        Yes, I probably should have been more clear on this: The optimal situation is of course desinging both the DB and the OO system at the same time. If one or the other already exist, it can indeed be problematic: When adding an ORM layer to an existing database, the issue is often that not all code accessing the database is going to be replaced at once, so for example a common situation is someone deciding to implement some validation logic in the OO system, which is bypassed by all the other legacy code going directly to the DB - some will argue that the logic belongs in the DB instead, others will argue that the legacy code will get replaced anyway. On the other hand, I can imagine the situation you mention (having an existing OO API that now needs to be mapped to a DB) might be tricky as well, though I personally haven't been in this situation so I'm having trouble imagining how it might occur - perhaps if the objects were previously serialized in some other way...

        Are you an active user of DBIx::Class ?

        Not at the moment, but I have used it in the past, along with another ORM framework in Java (maybe two, it was a while ago).

Re: Terminology: Is DBIx::Class an ORM?
by haj (Curate) on Jun 02, 2021 at 17:01 UTC

    In the section "Description" DBIx::Class calls itself an SQL to OO mapper with an object API inspired by Class::DBI, the latter, according to its introduction, provides a convenient abstraction layer to a database. This description seems like a good match to me.

    On the other hand, I am not aware of test suite which a product must pass to be called an ORM, and of course, the truth is available on the internet. List of object–relational mapping software lists DBIx::Class as the only Perl ORM (whereas Ovid once collected about 30 for a talk), and the module even has its own (lousy) entry.

    So, well, it can't be wrong to call DBIx::Class an ORM.

Re: Terminology: Is DBIx::Class an ORM?
by erix (Prior) on Jun 04, 2021 at 14:17 UTC

    Opinion wrap-up:
    
    LanX: poses the question.  It sounds like he seeks to get  DBIC to be exempt from the bad reputation that ORM's have for some/many (?) people (never mind whether the bad rep is deserved or not) by way of un-ORMing it into something else.
    
    LanX's colleague:  DBIC is ORM (sounds like bad feelings)
    
    cavac: Sounds kinda slow (= bad feelings)
    
    haukex: DBIC is ORM (no bad feelings)
    
    haj: DBIC is ORM (maybe some bad feelings but blames DBA)
    
    Arunbear: DBIC is an ORM (no bad feelings)
    
    erix: 'who needs ORM or ORMy stuff?!' - bad feelings, but not deeply: I can imagine that it can be handy when:
      - multiple underlying DBMS (although, I severely doubt 
      - SQL/DBMS-challenged developers, or DBAs keeping devs at arms' length of the DB.
      - separating SQL from applications in large projects (in smaller projects much less useful, I'd say; maybe even bad
    
    Looking at that (alas, n=small), it is conspicuous that there are no strong arguments in favour of ORMs nor is there any strong language against ORMs. Maybe the difference is not so important, whatever the terminology.
    
    

Re: Terminology: Is DBIx::Class an ORM?
by cavac (Curate) on Jun 02, 2021 at 13:29 UTC

    A way to represent a data model in OOP where every table is a class, and every row an object of that class.

    Sounds kinda slow, especially working with large data sets.

    perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
      An OO front-end doesn't necessarily mean that the implementation at the back-end is slow.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

Re: Terminology: Is DBIx::Class an ORM?
by LanX (Sage) on Jun 02, 2021 at 15:14 UTC
    >   object <-> relational mapper.

    OK I guess the point is in the bidirectional arrow.

    Classical ORM is limited by the fact that it's mapping unidirectionally object language -> relational language.

    Ribasushi's title seems to indicate that he can also map all relational semantic back, hence <->

    Not sure if that kind of cleverness in the title is good marketing.

    🤔

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      Classical ORM is limited by the fact that it's mapping unidirectionally object language -> relational language.

      I think I maybe see where you're coming from here. Are you talking about the automatic generation of a new OO API definition from an existing database schema, and the reverse operation of automatically generating a new database schema from an existing OO API? In that case, my answer would be: I thought several ORM frameworks are capable of that? It's been a while since I worked with them though so I'd have to look it up, which I don't have the time for right now, plus I'm not sure if I'm understanding your question correctly...?

        > Are you talking about the automatic generation of a new OO API definition from an existing database schema, and the reverse operation of automatically generating a new database schema from an existing OO API?

        No.

        The fundamental definition of an ORM I found is to hold data model inside an object system which is made persistent with a DB server.

        That means mapping in one direction and the "data language" is limited to the semantics of the OOP model.

        But that's a one way street.

        Like with "Active Record".

        > I thought several ORM frameworks are capable of that?

        That would surprise me.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

A reply falls below the community's threshold of quality. You may see it by logging in.