Earlier quoted context omitted.
Ok, what's your alternative for validating an email address?
To use a parser that can validate RFC5322 p 3.4.1
A parser such as ....?
What ORMs have taught me: just learn SQL (2014)
641–650 of 654 posts
Re: What ORMs have taught me: just learn SQL (2014)
#642Earlier quoted context omitted.
Calling code is the front end... API services separate that calling code from the backend.
your backend is still storing data somewhere right?
Yes, but I'm not sure I get the benefit of decoupling the schema, I'm still coupling to the stored procedure interfaces, and still have to deal with the shape of input and results.
Re: What ORMs have taught me: just learn SQL (2014)
#643Earlier quoted context omitted.
A data mapper is not an ORM, it's a data mapper. It's a different access pattern. But I do agree that data mappers tend to be better.
This is the 'data mapper' vs 'active record' debate and I would argue both are sub-categories of 'Object-relational mapper.' I've seen multiple people in this thread even include query builders in their definition of ORM. I'm starting to wonder if much of the disagreement in this thread is caused by everyone having their own definition of ORM.
My comment wasn't meant to be a refutation of anything, merely an observation.
Re: What ORMs have taught me: just learn SQL (2014)
#644Earlier quoted context omitted.
your backend is still storing data somewhere right?
Yes, but I'm not sure I get the benefit of decoupling the schema, I'm still coupling to the stored procedure interfaces, and still have to deal with the shape of input and results.
If schema needs to be changed in many cases sp interface will stay the same e.g. I can do changes/optimizations to schema without changing the calling code.
Re: What ORMs have taught me: just learn SQL (2014)
#645Earlier quoted context omitted.
What a weird statement. In many ways, SQL is a higher-level abstraction than an ORM. A better analogy might be functional versus imperative styles, but even that breaks down pretty quickly. ORMs generally serve some subset of three purposes: 1) constrain the dynamic nature and expressiveness of SQL in such a way that it can work well in less expressive languages 2) serve as a bridge between a typed language and an un…
> 3) a way to avoid your team needing to learn and work in two languages for backend dev (similar to arguments of using Node so that your frontend and backend can be the same language) It's not about learning or working in multiple languages, it's about duplicating the specification of important details. The holy grail would allow me to write critical business rules in one place, then make use of them everywhere. I w…
Well, there is the option of writing all your CRUD methods as stored procedures which are the things that actually create/update records (while still allowing complex reporting queries), but that means writing all that logic in the provided SQL language.
That was one of the most interesting things to me about the Drizzle MySQL fork project. One of the goals was to make the SQL language that was used a plugin, so you could use just about whatever you want, JavaScript, Perl, Python, Ruby, Haskell, whatever, as the SQL server level. Being able to share client and server level code opens up some interesting possibilities. Alas, I think it ended up being abandoned.
Re: What ORMs have taught me: just learn SQL (2014)
#646Working with SQL was nicer in PHP. It gets more difficult for some reason in Node/JS. SQL injection would always be a concern by default when writing raw queries. Though I think I could avoid writing flawed queries/endpoints, it's harder to expect that from a team at scale. #foodforthot
Re: What ORMs have taught me: just learn SQL (2014)
#647ORMs lure you in with a false sense of neat abstraction. They have nice intuitive examples on their home pages. But then you use them in the real world, doing gnarly queries, and you realize that doing anything powerful and fast in the ORM requires its own completely separate abstractions, which are often difficult for the uninitiated to follow. It's also often a big pain to debug the raw SQL that gets compiled after…
Software is full of this stuff.
I remember the very first time I had to do anything interactive on a web page. We had a long list of items in a table, and as a stopgap for adding search functionality we were going to sort the table by multiple columns.
Stack Overflow was still a twinkle it Atwood's eye. So I go googling about for stable sort implementations in Javascript and I find plenty. Except they all have the same problem. They were all slow as molasses. I should have taken it as a huge warning that none of these implementations used demos showed sorting of more than 10 items.
I needed to sort 100 items. 300 at the outside. Ultimately I had to go to source material and implement it myself.
Clearly there is some notion in the software community that market for ideas is inexhaustible. That the 'oxygen' in the room is infinite, and therefore I can interject whatever half-assed concept I had into it without costing anybody anything.
Virtually all of us, when we tackle a problem, try to do better than what is already on offer. But what if the thing on offer is truly, horrible? If my only goal is 'better' instead of 'good', then my alternative will be really bad. And in a field full of bad, who wants to be the person who introduces the 6th standard? The 8th?
Keep your dumb ideas to yourself, or put them in question form and ask people why
After someone posted Norvig's Sudoku solver, I was troubled by his statement about how many algorithms he'd have to implement so he just did brute force. So I took a whack at it, got fairly far down the deductive path before things got hard. But I'm not going to show it to everybody. The internet has been working on strategies for 10 years, and they've done way more algorithms than the ones I knew about. The best I've managed is to maybe simplify a couple rules, but I think one could argue that it's the bad definition of 'simple'. It can't handle as many cases, but I can explain it to anyone. Is that enough to add to the noise? Probably not.
Re: What ORMs have taught me: just learn SQL (2014)
#648Earlier quoted context omitted.
The typical language people use is imperative language where you state how to do something, while sql is a declarative language where you say what you want. Since we are in the world of analogies, using an ORM is like taking a shovel and using it as a prop (without speaking) to explain excavator operator where to dig, how deep, how wide, what things to avoid etc. Except querying a database can be much more complicate…
How is this standard C# code to work over a list: var males = from p in context.Person where p.Sex = “M” select c; Any more imperative whether context represents a C# object or a database?
Well, LINQ is special, it is a language that is similar to SQL that's inside of another language. Such code then is translated to SQL. The language is still not SQL but SQL-like and is incomplete, for example you can't do CTE in it.
Re: What ORMs have taught me: just learn SQL (2014)
#649Earlier quoted context omitted.
Ding ding ding. Dedicated read replica and an ETL gets you to a point where queries don't bring down prod. If you have an analyst org running wild making bad decisions about data that they think says things it doesn't -- that's probably a good sign that it's time for a dedicated data engineering team, and potentially a BI flavored data science team as well.
Analytics queries bringing down prod seems . . . pretty amateur hour. I'm more interested in whether or not analytics queries actually get the data they're interested in when they want it. The reporting team is likely not better versed in what means what than the developers who work on the application databases. What about multiple internal DBs that reporting wants to analyze as if they were one? What about schemas t…
> Reliable, versioned data access APIs address both of those families of problems.
They only address it in so far as they push it downstream to the analyst, who as you mentioned, "is likely not better versed in what means what than the developers who work on the application databases."
There's a reason why datalakes exist, and having used them at past N companies, I think this is why data engineering of the BI flavor becomes necessary at the point that reporting becomes critical. An API is strictly worse than a datalake, and it's not hard to set up and maintain the latter. API versioning and communication are for frontend integrations, paid partner integrations and potentially (although I'd probably lean more on gRPC and the ilk) microservice to microservice interactions. But, I like to avoid building unnecessary API surface when I can.
Re: What ORMs have taught me: just learn SQL (2014)
#650Earlier quoted context omitted.
Make it a product and sell it/github it.
I'd happily github it if it would fit more use cases, is it something you think others would be interested in?
One or two blog articles featured here, clearly explaining the difference in philosophy/architecture, and the advantages it has over ORMs, and you will have an audience.