Ruby 3.3 - Hackdot

Re:Ruby 3.3 by pmontra on Monday December 25, 2023 @06:18AM (#38761687)

My customers are using Celery for Python and Sidekiq for Ruby. Those are parts of Django and Rails web apps. Those customers don't mix languages so they don't need workers able to run code in multiple languages. One of them is also using SQS though so we could receive a JSON in a server written in any language, do some processing and return the result. However the database of that app has been "destroyed by design" by using Django's ORM inheritance (my suggestion: never use it) so nothing can interact effectively with it except Python code using the same models.

By the way, celery was born as a protocol spec to support multiple languages but never moved past Python. I can't google a quote for that, I remember I saw it years ago in the documentation somewhere.

[ Parent | on HN ]

Re:Ruby 3.3 by rjzzleep on Monday December 25, 2023 @10:14AM (#38763245)

I can see that it was born that way, but nowadays most job queues say, don't touch the wire protocol, it's not intended to be used directly.

I still think Rails has the best ORM design I've ever seen, iterated with practical applications. Django's ORM and migrations are, for lack of a better word, odd.

I'm a bit surprised that people here argue that no one using Rails would ever want to interface with other languages. Most big companies do. How can you not interface with python these days.

Looks to me like celery might just be the only job queue left like that. Might be worth writing a current ruby en-queuing library for it. Retracting my previous statement about ActiveJob since it would probably be too much effort to execute anything bidirectionally.

https://docs.celeryq.dev/en/stable/internals/protocol.html#

[ Parent | on HN ]

Re:Ruby 3.3 by riffraff on Monday December 25, 2023 @12:03PM (#38764168)

What's wrong with Django's orm? Does it have something particularly bad compared to others?

[ Parent | on HN ]

Re:Ruby 3.3 by cdcarter on Monday December 25, 2023 @02:17PM (#38765257)

I think the poster is specifically referring to using inheritance in Django ORM, where if you had e.g. a model Book and then a model Novel that inherits from it. In python these are modeled as a class inheritance hierarchy, and Django (at least, by default) creates a database table per class in the hierarchy. If you have 3-4 levels of inheritance, that's 3-4 extra joins per query.

[ Parent | on HN ]

Re:Ruby 3.3 by pmontra on Monday December 25, 2023 @03:17PM (#38765729)

This. That customer of mine started a project a few years before hiring me. They used inheritance and each model is scattered around a number of tables. No external tool can sensibly access that database, except that very Django app and its manage.py commands. Add a similarly enthusiastic use of apps under the same main directory and the database is a mess of long named tables with a tangle of relationships between them.

We started another project later on and we planned the database first. We wrote one model per table, no inheritance, only a few cleanly delimited apps. We still use makemigrations and migrate but if we want we can write a piece of software on any language to access that database.

[ Parent | on HN ]

Re:Ruby 3.3 by mixmastamyk on Monday December 25, 2023 @02:32PM (#38765389)

We use that, a base model and some mixins, but we use Meta.abstract=True (or similar, not at my desk) on the parents and have not noticed any issues, though have not looked for them either! Should I be concerned?

[ Parent | on HN ]

Re:Ruby 3.3 by cdcarter on Monday December 25, 2023 @02:37PM (#38765441)

That works fine. It's when you inherit from a non-abstract model that you end up with the trickier data model.

[ Parent | on HN ]

Re:Ruby 3.3 by riffraff on Tuesday December 26, 2023 @02:06AM (#38769500)

Oh, got it thanks

[ Parent | on HN ]