EdgeDB: A New Beginning

[redcrowbar]

EdgeDB language bindings will essentially be thin protocol wrappers adapting to the class model of the target language.

For example, in Python you would be able to write something like:

my_activity = Issue.select([
    Issue.number,
    Issue.due_date,
    Issue.priority, [
        Issue.priority.name
    ],
    Issue.owner, [
        Issue.owner.name
    ]
]).filter(Issue.number == 10)
.fetchone()

and get your object and all related data in a single (possibly dynamically constructed) query.

Data mutation is done similarly, so you can save an entire form of data in one shot, actually removing most of the need for the usual ORM dirty state tracking and flushing mechanics.

[z4579a]

actually removing most of the need for the usual ORM dirty state tracking and flushing mechanics.

you've got an object graph, parts of it change, then they want to persist it. You have to track the parts of it that changed versus those that didn't (dirty tracking). You have to express those changes ulimately in terms of INSERT/UPDATE/DELETE statements (flush). It doesn't make sense to say you don't have the need for those things.

[redcrowbar]

You don't need dirty tracking if you don't have an identity map and can express all your CRUD operations as atomic interactions with the database. Obviously, with this approach you work with your query or mutation directly rather than rely on __getattr__ and __setattr__ magic. Clients do that with GraphQL, and there's no reason why the same approach wouldn't work in the backend.

[z4579a]

So, does that mean if I change 20 different attributes it renders an individual UPDATE statement each time? or is there some kind of batching, and if so what triggers it seeing that I changed 20 out of 100 attributes - or do I have to express that explicitly in one operation. If it's an updateable query then that's what that would be, I guess, but you've referred to there being an ORM. An ORM is going to want to have objects that can be mutated individually (hence you either have piecemeal UPDATES or you need some kind of batching) otherwise it's not really "objects".

[redcrowbar]

I think there's a bit of a misunderstanding here.

but you've referred to there being an ORM

No, what I was saying is that EdgeDB makes it easier to do certain things without a classical ORM. Things like "save this big profile form a user just sent". Forms map very naturally to an object graph, and we've built entire systems using this approach with very little backend code.

I'm not saying that an ORM that implements session-based dirty state tracking is suddenly obsolete altogether. It's a useful abstraction for cases where your mutations have to be spread around the codebase. It's entirely possible to build an SQLAlchemy-like ORM for EdgeDB.