|
TheFluff posted:query builders/sql metaprogramming tools are usually p dang handy on the application side though. SQLAlchemy, jOOQ, that sort of thing. can confirm (N)Hibernate is poo poo with hibernate you need to be so careful designing your entities that your domain model usually has to change in order to fit the orm than the other way around. and if you need multiple lazy loading/fetching settings depending on the query then good luck with that. just add more annotations you better not gently caress up
|
#
?
Apr 9, 2019 19:38
|
|
|
|
| # ? Dec 6, 2024 22:46 |
|
|
Finster Dexter posted:cjs: just finished a shouting match between me, CTO, and CEO... choice CEO quote: "small, quick tasks will always be higher priority than bigger tasks even though the small tasks might be less important from a business standpoint." Sounds like they need a scrummaster to yell at instead!
|
|
#
?
Apr 9, 2019 19:53
|
|
|
honestly given how easy sql actually is I struggle to think of a case where a full fat orm is actually a benefit. like dapper owns because you can a use it as just an auto mapper and save some boilerplate, and yeah you can do stuff like embed lambas to split dataset outputs but you know what? If you're doing that poo poo you need to look at your data source queries and think "am I being too clever here?" just write some procs that query views and if its slow either unfuck your query to not return a billion rows in an embedded expression then distinct them (!) or add the index you probably forgot about because you were gonna come back and add them after you created the table but db janitoring is boring so you didn't edit: select em all 1989, I am ANSI man, 27193736 returned rows
|
|
#
?
Apr 9, 2019 21:37
|
|
|
i feel like i know juuust enough about the pitfalls of relational databases that the idea of an ORM makes me do the  face. i would be constantly checking the SQL output of the ORM if i used one, so uh at that point is there even any benefit?
|
|
#
?
Apr 9, 2019 21:59
|
|
|
Ignore what the ORM puts out until a new query floats to the top of your database monitor's "Bad Queries" report, imo.
|
|
#
?
Apr 9, 2019 22:08
|
|
|
CPColin posted:Ignore what the ORM puts out until a new query floats to the top of your database monitor's "Bad Queries" report, imo. but with so many bad queries how would you choose???
|
|
#
?
Apr 9, 2019 22:49
|
|
|
Choose whichever query your boss wrote
|
|
#
?
Apr 9, 2019 22:54
|
|
|
99 times out of 100 i'd rather work with a shallow api on top of raw sql than an orm the 1 time an orm works falls apart like 1 business requirement later but there's often a reasonable sql builder solution somewhere between raw sql strings and a full blow orm
|
|
#
?
Apr 9, 2019 23:19
|
|
|
DaTroof posted:99 times out of 100 i'd rather work with a shallow api on top of raw sql than an orm username/post combo
|
|
#
?
Apr 10, 2019 01:15
|
|
|
gently caress the query optimiser though
|
|
#
?
Apr 10, 2019 01:17
|
|
|
pseudorandom posted:I'm both a couple days late and too lazy right now to actually investigate your code, but is there any reason you're going lower-level with hyper/tokio rather than one of the higher level frameworks? Rocket was really easy for simple projects, but I've moved over to Actix for my more recent toy projects. I would definitely recommend using a framework for Rust web things, unless your project is a web framework itself. pseudorandom posted:Look at this guy, graduating high school in 3 years. I was probably 7-11 too, but years are hard  Powerful Two-Hander posted:honestly given how easy sql actually is I struggle to think of a case where a full fat orm is actually a benefit. like dapper owns because you can a use it as just an auto mapper and save some boilerplate, and yeah you can do stuff like embed lambas to split dataset outputs but you know what? If you're doing that poo poo you need to look at your data source queries and think "am I being too clever here?" EF is cool when you have to write an OData-compliant API oh god why
|
|
#
?
Apr 10, 2019 01:35
|
|
|
Beamed posted:OData more like NOData
|
|
#
?
Apr 10, 2019 02:12
|
|
|
I would rather work on a system with bad Devs misusing ORM rather than a system where bad Devs misuse SQL. With bad ORM you still have the option to drop down to SQL to try to save something, but with just SQL the cancer has settled down to the bone.
|
|
#
?
Apr 10, 2019 03:00
|
|
|
if you can’t replace a resource’s storage from a database to a remote service without changing all the loving application logic everywhere then you hosed up your isolation and abstraction layers and you gotta go back and rethink that interface the view or controllers in an app should have no loving clue whether you’re using an ORM or not for the data model or handling. if you do, congratulations you’ve built everything on top of a leaky abstraction. go sit in a corner and think about what you’ve done
|
|
#
?
Apr 10, 2019 03:11
|
|
|
elcannon posted:Probably the most useful take I've gotten from reading this thread over the years is that the application layer has no business owning the database layer and that ORMs inevitably end up with people blowing off their own foot and then just shrugging it off because at least they don't have to touch SQL. counterpoint: people who dogmatically avoid ORM just wind up implementing one themselves badly
|
|
#
?
Apr 10, 2019 04:39
|
|
|
prisoner of waffles posted:so glad I don't work with EF anymore Entity Framework was a hastily-created me-too response to Hibernate and Core Data
|
|
#
?
Apr 10, 2019 04:40
|
|
|
MononcQc posted:if you can’t replace a resource’s storage from a database to a remote service without changing all the loving application logic everywhere then you hosed up your isolation and abstraction layers and you gotta go back and rethink that interface once again with the wisdom this has been something I’ve tried to teach people with the Core Data code generation feature in Xcode 8 & later like, it’ll generate classes for your entities at build time, and you can just import the headers and use them, add extensions/categories on them, and so on, and all that is great to get code completion, business logic, and so on but what we don’t do is let you expose those classes as public or even private API, only as internals within your module, in part because you really shouldn’t be exposing build-time generated code (which can change from release to release) as API if you’re going to expose it the least you could do is invoke the static code generator (it’s just a menu item, we didn’t take it away) and put the results in your project as “real” sources with comments and API versioning markup and all that good stuff (or better, don’t, and think more carefully about the API you’re exposing to clients)
|
|
#
?
Apr 10, 2019 05:09
|
|
|
Edit: Removed; I'm probably too inexperienced/dumb to comment on this. I'll keep this from my original post: I'll admit, I've never worked in an Enterprise environment, so maybe I just don't Get It. pseudorandom fucked around with this message at 05:12 on Apr 10, 2019 |
|
#
?
Apr 10, 2019 05:09
|
|
|
at least one of the advantages of a good ORM is that it can enforce constraints at both the database and application level by letting them be specified in one place some attribute has a length restriction, or a formatting restriction? specify it in the model and it can flow to both the database (regardless of back-end) and to the UI (regardless of the front end)—this was the huge advantage of NeXT’s Enterprise Objects Framework for both AppKit and WebObjects application development you can also batch multiple modifications to the object graph into coherent updates, so either the whole changeset goes through or doesn’t, and you can get intelligent reporting as to why a particular changeset failed to apply (such as an optimistic locking failure, a constraint violation where some custom bit of UI didn’t actually read from the model, etc.); yes you can get this from transactions too, but again this is phrased in terms of your model and can be easily reflected in the UI in Core Data and EOF we also took advantage of this to allow things like automatic maintenance of inverse relationships, automatic serialization & deserialization of object properties to database-compatible representations, automatic support of (both infinite and batched) undo for modeled properties, and the ability to nest changesets
|
|
#
?
Apr 10, 2019 05:17
|
|
|
i love query builders but really any sort of janky metaprogramming bullshit is cocaine to me so my judgement probably shouldn't be trustedHoboMan posted:guess who got two thumbs and found plaintext passwords in the database? hows that going for you
|
|
#
?
Apr 10, 2019 05:49
|
|
|
Beamed posted:I posted about getting burned really hard by this a few months back, to the point where I wanted to write my own framework - it was at the height of the panic over Actix's tons of unsafe blocks, Rocket still being Too Unstable, and Gotham being abandoned (temporarily). Rust's web story still doesn't seem to be there. i've been using rouiille. it's synchronous but its fast enough to tide me over and let me use other more mature parts of the rust ecosystem until something matures. just internal tools only though.
|
|
#
?
Apr 10, 2019 06:01
|
|
|
pseudorandom posted:Edit: Removed; I'm probably too inexperienced/dumb to comment on this. if everyone "too inexperienced/dumb to comment" decided not to post, yospos would be a wasteland.  , and maybe some of us will learn something new, or see another side of a debate, or hear about another perspective
|
|
#
?
Apr 10, 2019 06:13
|
|
|
redleader posted:if everyone "too inexperienced/dumb to comment" decided not to post, yospos would be a wasteland. here's another perspective goatse.jpg
|
|
#
?
Apr 10, 2019 06:19
|
|
|
eschaton posted:counterpoint: people who dogmatically avoid ORM just wind up implementing one themselves badly This. If you're doing a CRUD app but using raw SQL you'll need to implement an Object-Statement mapper, a Statement-Object mapper, concurrency/versioning, aliasing, fetch strategy, caching, a statement mapper for different dialects if that's your bag etc. You've just written your own lovely ORM. The the decade or so we've been using Hibernate we've never had an issue related to how Hibernate generates querys. The closest we've had to a bug was when SQL Server wasn't query caching the parameterised queries correctly. But that turned out to be a config/JDBC driver problem.
|
|
#
?
Apr 10, 2019 06:46
|
|
|
Aramoro posted:The the decade or so we've been using Hibernate we've never had an issue related to how Hibernate generates querys. The closest we've had to a bug was when SQL Server wasn't query caching the parameterised queries correctly. But that turned out to be a config/JDBC driver problem.
|
|
#
?
Apr 10, 2019 07:14
|
|
|
Sagacity posted:well let me just say you are clearly in the wrong thread, sir! One of our current front ends still uses Struts 1.6, I've got plenty of terrible to go around.
|
|
#
?
Apr 10, 2019 08:14
|
|
|
Finster Dexter posted:cjs: just finished a shouting match between me, CTO, and CEO... choice CEO quote: "small, quick tasks will always be higher priority than bigger tasks even though the small tasks might be less important from a business standpoint." We've got a big task in the backlog to replace our home-rolled Lucene search with Solr. It's basically ready to go, probably a couple of weeks effort in porting stuff over. But it's constantly getting bumped out of iterations for things like styling changes and lovely new features. It's probably the biggest improvement we can make to the application in terms of platform just now but customers can't 'see' it so we're not doing it. It's just absolutely infuriating.
|
|
#
?
Apr 10, 2019 08:18
|
|
|
Beamed posted:EF is cool when you have to write an OData-compliant API oh god why we use microsoft's odata library and i'm sure it made it easy for them to write but holy gently caress ef is a loving disaster in this project. ef can take a good 10-15 seconds to prepare a query it's never seen before, and in odata new queries happen all the time. sure, ef has some great caching so once it's calculated it once it'll be super fast, but odata aggregates leak cache entries and the ef cache can only hold 800 items. to make matters worse, the ef cache sweep that triggers once it hits 800 items is so brutal that if you regularly hit this limit it will dump the entire cache causing every single query to rebuild no matter how regularly it was hit. it was so bad that we had to decompile ef to change the cache handling to make it less of an rear end in a top hat. that combined with branching the microsoft odata project to fix some dumb bugs in that and to get our ef dll to run means our odata solution is a loving clown car of projects. gently caress odata and gently caress microsoft's inability to write a single coherent codebase for their "open standard".
|
|
#
?
Apr 10, 2019 09:47
|
|
|
is anyone really using odata outside microsoft (and companies that drank microsoft's koolaid)? asking for a friend i recently spent some time odata'ing because i needed to connect to the azure graph api and it was okay, i guess. being able to specify which fields to include is nice, but there are all sorts of bizarre restrictions on which nested relationships you can follow and which ones you can't etc
|
|
#
?
Apr 10, 2019 12:49
|
|
|
Sagacity posted:is anyone really using odata outside microsoft (and companies that drank microsoft's koolaid)? asking for a friend a bunch of things have connectors for it out of the box which makes it better than a random roll your own api. that said, the only ones people actually use in my experience are the excel and power bi connectors so it is pretty much microsoft all the way down.
|
|
#
?
Apr 10, 2019 12:52
|
|
|
eschaton posted:counterpoint: people who dogmatically avoid ORM just wind up implementing one themselves badly in which case they have created exactly the same thing as every other orm and lost nothing
|
|
#
?
Apr 10, 2019 14:45
|
|
|
the only thing i know about odata is that Microsoft graph uses it and Microsoft graph is slow as gently caress
|
|
#
?
Apr 10, 2019 14:46
|
|
|
eschaton posted:at least one of the advantages of a good ORM is that it can enforce constraints at both the database and application level by letting them be specified in one place if you're applying validation in the model and not in the orm how is the orm helping you? also the entity layer in ef is absolutely the worst part about it because you spend more time writing code to manage entities in memory than you ever would have writing sql w/ a statement mapper.
|
|
#
?
Apr 10, 2019 14:49
|
|
|
MononcQc posted:if you can’t replace a resource’s storage from a database to a remote service without changing all the loving application logic everywhere then you hosed up your isolation and abstraction layers and you gotta go back and rethink that interface typical orm use is to not do any abstraction and use orm code in your controllers. this is because orms are promoted as that thing that does the abstraction between the application and data source. statement mappers are litterrally a way to map your abstraction interfaces to statements in your data store.
|
|
#
?
Apr 10, 2019 14:58
|
|
|
the object-relational impedance mismatch isn't a real thing, just write the drat sql (using a query builder obvs not raw strings)
|
|
#
?
Apr 10, 2019 15:32
|
|
|
hibernate seems to have the worst of both worlds; you have queries as strings, but they're not sql, they're some idiot pseudo-sql 
|
|
#
?
Apr 10, 2019 15:39
|
|
|
I'm using ef core on a small service right now and it's very needs suiting.
|
|
#
?
Apr 10, 2019 15:45
|
|
|
TheFluff posted:hibernate seems to have the worst of both worlds; you have queries as strings, but they're not sql, they're some idiot pseudo-sql Only if you choose to use HQL, queries are not string in general for the last maybe 10-11 years? If you're using an statement mapper then you're already writing pseudo-sql. Terrible Programmer : I need to 'see' the SQL getting run to ensure it's correct, I just don't trust it! Also Terrible Programmer : *use a SQL query builder and statement mapper*
|
|
#
?
Apr 10, 2019 15:45
|
|
|
MononcQc posted:the view or controllers in an app should have no loving clue whether you’re using an ORM or not for the data model or handling. if you do, congratulations you’ve built everything on top of a leaky abstraction. fwiw, this is just typical, though You're absolutely right, but I've never met a web app that wasn't just handing views ORM-based model objects to extract data out of. I have this theory that our programming languages just aren't good enough at quickly and easily describing intermediate data types (and transforming to/from them) that we all just tend to skip doing that pretty aggressively.  DELETE CASCADE posted:the object-relational impedance mismatch isn't a real thing, just write the drat sql (using a query builder obvs not raw strings) it's real, it's just a lot narrower than people give it credit for. "don't try to match tables 1:1 with classes, because projection and joins," well golly.
|
|
#
?
Apr 10, 2019 16:09
|
|
|
|
| # ? Dec 6, 2024 22:46 |
|
|
animist posted:hows that going for you asked the client about it and the client says they are using "microsoft" for the application validation so don't worry about it
|
|
#
?
Apr 10, 2019 17:22
|
|
