111–120 of 144 posts
Earlier quoted context omitted.
Relational model is good, SQL is not. They are not the same thing.
Short of academic languages like D, nothing faithfully implements the relational model. Some compromises are necessary to make it useful for practical applications, hence SQL.
SQL has other warts, apart from not being completely relational.
Earlier quoted context omitted.
Something in the official docs or more like shared through blogs or stackoverflow ?
It's in the standard docs: https://docs.djangoproject.com/en/5.1/topics/migrations/#ver... You just rename one of the two files, and add the dependency. If they touch the same fields, you obviously have to resolve that manually.
orms are exercises in OCD. Databases are the bottleneck your classic website. We choose to query these databases in a extremely high level language called SQL. This language is so high level that you need to come up with tricks and query analyzers in order to hack the high level query into something performant. A better abstraction would be one that's a bit more similar to a standard programming language with an std…
> This language is so high level that you need to come up with tricks and query analyzers in order to hack the high level query into something performant. What? You have to understand a language to write performant code in it. That’s not a hack, that’s basic competence.
The poster is not referring to understanding the language, he/she is referring to having to guess at how to structure the query in a way that increases the chances that a good plan is within the constrained search space of plans (due to it being a combinatorial problem and the optimizer has limited time and information).
Earlier quoted context omitted.
It's in the standard docs: https://docs.djangoproject.com/en/5.1/topics/migrations/#ver... You just rename one of the two files, and add the dependency. If they touch the same fields, you obviously have to resolve that manually.
Thanks a lot
Earlier quoted context omitted.
> For pythonistas reading this: JVM and .NET frameworks are better for large projects in the sense that they turn even the simplest projects into large messes of pointless byzantine buggy architecture, which in some circles is a sign of "high quality". You got to back up this claim. The technologies you mentioned are entirely orthogonal to the architecture you are using.
https://spring.io/guides/gs/spring-boot
The Java equivalent to Django ORM would be Hibernate.
It doesn't strike me that you know what Spring does, nor where its own features end.
Earlier quoted context omitted.
That's the problem I have with Python mentality. Everything is great, you just need to know about the myriad of pitfalls and problems. A good environment makes problems obvious and and allows to communicate decisions clearly. This is the trap of the local maximum.
> ..with Python mentality As opposed to what mentality ? I mean any tool I worked with has the same problem.
> > Everything is great, you just
Part of the python mentality is to pretend difficulties aren't there in order to keep presenting itself as beginner-friendly.
Earlier quoted context omitted.
And the title of Software Engineer becomes even more meaningless. Imagine an electrical engineer saying, “I don’t really know what a bridge rectifier is, but I plugged these things into the breadboard where ChatGPT told me, and the output signal looks correct.”
The engineering is in saying "I need to get this data within these performance constraints", not in the now worthless knowledge of exactly how to fetch it.
The other person is the engineer here.
Earlier quoted context omitted.
LLMs are not at a point where we should be treating them as a solution to any software engineering issue, period.
I've used it to write horrendously complex queries across multiple tables. It can do things I don't know how to and that would have taken significant time to learn. All I know is it works and it's performant when you tell it to be. It's been particularly helpful for aggregations, subqueries etc. You may not think LLMs are there yet but my project is proof. Try it yourself.
This isn't something new.
Earlier quoted context omitted.
The engineering is in saying "I need to get this data within these performance constraints", not in the now worthless knowledge of exactly how to fetch it.
That’s not engineering, it’s operating. There’s nothing wrong with operators as a career field, but don’t equate it to engineering, and don’t expect to be as highly paid (why should you be? You can’t fix it when it breaks, and you don’t know how it works).
Earlier quoted context omitted.
Aren't Django models close enough to types?
Nope. Python type hinting is far far from Java like types. And yes, I guess OP has now a large system that needs types enforced by the system to reduce the friction in evolving the stack.
> Note: The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc.
Then yes, Django model definitions are more like Java types in that they error if you try to use an incorrect type. You can't just ignore them like with type hints.
They also try to be 1:1 with database types, so for the most part any additional validation added on top of Django would be something you had to do anyway.