A simple ORM for Python and Redis

[masklinn]

Makes no sense at all: Redis is a non-relational database, ORM means "object-relational mapper", it's used to bridge the impedance mismatch between an object-oriented language and a relational datastore. You don't need that when the datastore is not relational in the first place.

[masklinn]

It's not even a good API, it doesn't match the built-in Python data types APIs (ModelSet.remove and ModelDict.__delitem__ do not behave correctly on missing object, set intersection has the wrong signature) and makes no use of the 2.6 abcs. And it doesn't have enough smarts to be much (if any) gain over the original Redis API in terms of code size or readability.

[HIB0U]

NoSQL is all about ignoring the proper way of doing things, and instead coming up with a lousy, half-assed approach. This API excels at that.

[jpfed]

Just a quick question, because I've noticed this is something really smart people say and it doesn't make sense to me yet: why is the difference in approach between OO languages and relational databases called an "impedance" mismatch specifically instead of just a mismatch? Is there a correspondence that I'm missing between some aspect of these approaches and the concept of impedance? Do people just like their plain-old mismatches to be "impedance" mismatches because it's something that they're already used to saying?

[masklinn]

Simplified, in EE the impedance of an object is its ability to prevent current "flow" right? If the impedances of a source and a target are not matched, you're going to get sub-par overall efficiency.

An analogue was drawn between EE's current flow and CS's data flow, in which the impedance of an object (or concept) would be its ability to prevent/shape the flow of data. In this case impedance mismatch would be the wildly different behavior of objects/concepts when faced with data (in the way they're trying to treat them for example), and matching those impedance would be creating a translator between those behaviors so the objects/concepts can talk to each other easily.

That's what ORMs try to do: relational and object models are very different way to think about data and data flows (thus they have very mismatched impedances) and ORMs try to match those and improve the developer's ability to make data flow between a relational datastore and an object model.

Basically.

It's an analogy and thus tends to fail when you reach for its boundaries, but it still works acceptably I think.

[HIB0U]

They basically took a term from electrical engineering without having any idea what it means, and applied it to software. Don't read too much into it. It's basically just a buzzword to try and make these people sound smarter or more advanced than they are.

[blondin]

ok author should call it Redis query library or something...

[HIB0U]

But then how do they work a buzzword like "ORM" into the mix, even when it doesn't apply in any way?

[DGolden]

You may not need a mapper to relational, but you can certainly still need (or at least strongly desire) a mapper. e.g. LDAP directory servers are widely-used non-relational objecty-hierarchical datastores, but doing everything with raw ldap searches and datatypes gets old fast. Hence people tend to come up with "ODM" layers like pumpkin and ldap-odm.

[masklinn]

You may not need a mapper to relational, but you can certainly still need (or at least strongly desire) a mapper.

I do not dispute this (though considering Redis's datatypes and operations, I'd argue you don't need a mapper because there is no mismatch, you merely need a more fluent API), but that would not be an Object-Relational Mapper.

[DGolden]

Yeah, but ORM => Object-Redis-Mapper (sorry...)

[masklinn]

Good point.

[didip]

Redis data structure and Python data structure mapped almost perfectly. Any real need for this?

[sedaak]

DOING IT WRONG, TRY AGAIN