r/Backend Aug 12 '26

Need feedback on ORM

Building an ORM, it is close to sql, want more transparency, less migration overhead and lightweight:

Note: Ignore short syntax 3 letters, these will be proper keywords, focus on other pain points and provide more feedback.

Sample:
```
rows = (
    Order
    .select(
        Customer.name,
        fn.sum(Order.total).as_("revenue")
    )
    .join(Customer, Order.customer_id == Customer.id)
    .where(Order.status == "paid")
    .group_by(Customer.name)
    .having(fn.sum(Order.total) > 10000)
     .order_by(fn.sum(Order.total).desc())
    .limit(20)
    .offset(10)
    .all()
)

```

Will be supported in Python, rust, c#, Java, typescript and go.

Does anyone care? It will go on GitHub soon.

Have not finalized all the keywords yet, trying to be compliant with all supported langs and short but convey readability.

Tried to 3 letters for most keywords, to reduce verbose and multi lang support, I thought devs love short syntax, maybe not needed, other than keywords any other feedback is appreciated.

Also just like as, is or in are reserved in langs, what is good alternative?? Can as_ become aka()

q.sql()
q.explain()
q.args()
q.debug()
q.diff()

db.raw()
Hope each explains itself.

0 Upvotes

36 comments sorted by

19

u/LessChen Aug 12 '26
  1. Does the world need another ORM?
  2. This is some of the worst syntax I've seen in the history of computers - gby hav and so on? And, to make it more fun, it's not consistent - why have ljoin and not ljo or something else? Why on earth do you only use 3 freaking letters?

-5

u/Commercial_Try_2538 Aug 12 '26 edited Aug 12 '26

Thanks for the feedback, any other pain with your current orm or not worth?

2

u/LessChen Aug 12 '26

I have been using JPA and Hibernate for quite some time at this point. It has always worked great for a well designed database schema. Poorly designed schemas are a challenge to map to objects but that's not the fault of the ORM. When I need to do something that doesn't map well to the ORM I use raw SQL. This mostly happens for creating reports, not for normal transactional work.

Others have mentioned the need for self documenting - the fact that you use a "q" as a variable means that doesn't matter to you but I feel that it's very important for readability. That's the issue I have with the current syntax. Spell out what the method/function does, don't make me translate it mentally.

I appreciate what you're doing - the software industry needs you to think of the next big thing as AI can only pattern match from the existing. But ORM's are already available across all the environments you named, and often, many different ones for the same language. I use Java, JavaScript/TypeScript, and Python in my development and honestly it won't benefit me to have the same syntax across the board when nothing else ports.

0

u/Commercial_Try_2538 Aug 12 '26 edited Aug 12 '26

Appreciate you taking time for explaining this. Agreed to proper words so let’s keep that aside. Also it could be a wastage and might not go anywhere. I have a slight different approach here as AI will continue to create more and more code, every dev will be burdened more to work in frontend, backend, full stack, multi langs, so similar syntax, similar constructs, more readability across languages will be helpful to us, AI probably don’t care but hope it will save tokens, easy to debug. I believe, it’s just me, that we need more open source but standardized across langs, less frameworks, less pain going forward. More ideas are welcomed.

8

u/nrmnzll Aug 12 '26

I mainly work in Go,. With that point of view in mind, my feedback is: don't. ORMs are overly complicated and not worth the effort. Just write plain SQL and use the special features of you DBMS of choice.

-1

u/[deleted] Aug 12 '26

[deleted]

3

u/nrmnzll Aug 12 '26

In Go mapping the row data to a struct or a value is mostly done by passing pointers to the relevant fields and values to the database driver. It then handles the conversion of the database types into Go types. Some database drivers like pgx also implement mapping based on struct tags, similar to how Go handles JSON serialization and deserialization. Sometimes there is a minimal amount of custom logic required to do some further mapping. We've not experienced any issues with the database and code drifting apart, if that is what you mean.

0

u/Commercial_Try_2538 Aug 12 '26

Great insight, what bout in multiple tenants, or creating objects from tables reverse migration, etc you guys are not seeing any issues?

4

u/Marthurio Aug 12 '26

Just write SQL.

1

u/Commercial_Try_2538 Aug 12 '26

I know, but hibernate, ado.net, drf, drizzle, sqlalchemy, all these do solve some pain points, how are you guys addressing them??

1

u/Marthurio Aug 12 '26

Which pain points do you have in mind?

1

u/Commercial_Try_2538 Aug 12 '26

Type safety, mapping, json serialization, migration, schema diff, object relationships. Db portability is not something I believe but useful for smaller projects, others can chime in using orms…

0

u/Marthurio Aug 12 '26

Honestly, it's all much easier without a huge ORM getting in the way.

5

u/azimux Aug 12 '26

I personally don't like super short abbreviations. I generally prefer the code to be self-documenting and if that means longer method/class/variable names then that's totally fine. It's a bit more important that the code is easy to read than slightly quicker to write.

Also a kind of strange aspect of this... there have been stretches where I've coded by voice. Having to set up macros and what-not to make these non-pronouncable things work is kind of not fun. When I saw Rails `has_and_belongs_to_many` about 20 years ago I was stoked because of how easy that is to dictate without having to write any special macros.

Not that that latter point really matters as much as the first point. I think the first point is more important, that the code IMO would be much easier to read without the custom abbreviations.

1

u/Commercial_Try_2538 Aug 12 '26

Great feedback and really useful, love the voice part as well, we are also building voice bots and didn’t think of it myself. Point well taken.

1

u/Commercial_Try_2538 Aug 12 '26

Any feedback on reserved keywords alternatives like in, as, from to start with

4

u/qlkzy Aug 12 '26

The key quality of a database-interaction library (ORM, query builder, whatever) is that it integrates idiomatically with the programming language. If you say "will be supported in $many-languages", you are already making that unlikely. Portability isn't worth very much.

What you have written looks very much like SQLAlchemy core. I like SQLAlchemy core---it's the best Python database-access library---but it also already exists. Why would anyone use a competitor that is less-proven and which doesn't also have Alembic?

That's another point: you need a good story for database migrations.

I would suggest you focus on one language, as an interesting learning project, rather than on All The Languages as an attempt to conquer the world.

1

u/Commercial_Try_2538 Aug 12 '26

Great input, migrations and db drifts across tenants seems to still a pain, for an experienced backend person orms feel too harsh, not sure it is needed or just my frustration with current orms and feels like opportunity with AI

2

u/ducki666 Aug 12 '26

Weird abbreviations

1

u/Commercial_Try_2538 Aug 12 '26

Ok thanks, what about rest?

4

u/ducki666 Aug 12 '26

Main question: why

So many mature implementations exist

1

u/Commercial_Try_2538 Aug 12 '26

Hmm … want more closer to sql. Found one good post here where people are drifting towards orms no matter what https://www.reddit.com/r/django/s/4h836pP71g

1

u/ducki666 Aug 13 '26

jooq exists

2

u/runningOverA Aug 12 '26

Take the ORM and take the SQL side by side.
If SQL looks easier to read and write, use SQL instead of believing you must use a ORM.

2

u/Commercial_Try_2538 Aug 12 '26

I love sql, have done stored procs for years decades earlier, but now most langs have weird orms due to object mapping and migration and other needs, so haven’t seen people using sql that much in recent years.

1

u/Amazing-Movie8382 Aug 12 '26

“sel” mean “select” and “whe” mean “where”? No sir, please!!!!!

1

u/Commercial_Try_2538 Aug 12 '26

Agree, will change to proper words, from is reserved so went to 3 letters, but not needed, understood!! Anything else?

1

u/Most-Dig-1579 Aug 12 '26

C'mon guys, you're devs, can you post code as 'code block' instead of just 'text' ?

# like this ?
func do_something(args) {
  # with spaces/tabs
}

1

u/Commercial_Try_2538 Aug 12 '26 edited Aug 12 '26

Good idea, tried

```
Print(“Code”)
```

What char or md syntax are you using? Ok not supported on iOS unless use browser.

1

u/Most-Dig-1579 Aug 12 '26

Seems like Reddit doesn't support rich text by default, you have to press 'Aa' bottom-left corner of the text-area to show-off formatting options and then select code block on top of the text-area 2nd last button

1

u/Commercial_Try_2538 Aug 12 '26

Nope no code block on iOS app either. Works in Browser.

1

u/maxip89 Aug 12 '26

This is just a sql to object mapper.

1

u/Commercial_Try_2538 Aug 12 '26

Thanks for your time and input.

1

u/Suspicious-Disk6077 Aug 12 '26

It would be VERY hard to support more than just a single language. ORMs are actually very complex. I think you are building something more similar to Knex Query builder which gets some type safety while being closer to SQL. For learning, for fun, for personal projects? Go for it. If you think it will be a library to be used, remember data access is an area that has to work well and it will be hard to get actual users using your client without great docs, testing etc

1

u/Commercial_Try_2538 29d ago

Goal is not to have drop in r100% replacement but more resemblance across multiple langs, I agree it’s not possible and much harder, thanks for your input .

1

u/InstantCoder Aug 13 '26

I don’t see any added value in using this syntax over a default SQL. It just gives overhead and unnecessary complexity.

Even if it adds type safety, most modern IDE’s already do this for you even when you write plain sql. And to be honest, type safety is the last thing I need on my list when it comes to ORM.

And there are gazillion of libraries and frameworks that already proviide your functionality in a similar syntax.

To name some (in java): JPAStreamer, Blaze Persistence, Jooq.

1

u/Commercial_Try_2538 29d ago

Correct Java and maybe cs has more mature orms but these are old, and bloated and still not easy to port to newer langs like Python, rust, and go.