|
Re: Terminology: Is DBIx::Class an ORM?
by Arunbear (Prior) on Jun 02, 2021 at 22:22 UTC
|
| [reply] |
|
|
> 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.
| [reply] |
|
|
And where do you draw the line between ORM and SQL abstraction?
| [reply] |
|
|
Re: Terminology: Is DBIx::Class an ORM?
by haukex (Archbishop) 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?
| [reply]
[d/l] |
|
|
| [reply] |
|
|
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...
| [reply] |
|
|
| [reply] |
|
|
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).
| [reply] |
Re: Terminology: Is DBIx::Class an ORM?
by haj (Vicar) 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.
| [reply] |
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.
| [reply] |
|
|
- LanX: "Prose in code tags?" ( = bad feelings! )
:P
| [reply]
[d/l] |
Re: Terminology: Is DBIx::Class an ORM?
by cavac (Parson) 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";'
| [reply]
[d/l] |
|
|
An OO front-end doesn't necessarily mean that the implementation at the back-end is slow.
| [reply] |
Re: Terminology: Is DBIx::Class an ORM?
by LanX (Saint) 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.
🤔
| [reply]
[d/l]
[select] |
|
|
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...?
| [reply]
[d/l] |
|
|
> 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.
| [reply] |
|
|
|
|
| A reply falls below the community's threshold of quality. You may see it by logging in. |
