WTF Bites
-
@topspin nope - coturn is one piece of the puzzle.
Things get more interesting when you try to actually relay voice, for people who have shit connections (or if you're trying to make a lot of connections...)
-
@sloosecannon said in WTF Bites:
@error Slack was first for text chat.
They were just a glitzed up proprietary IRC chat ripoff.
-
@sloosecannon said in WTF Bites:
@error Slack was first for text chat.
They were just a glitzed up proprietary IRC chat ripoff.
Isn’t that what all of them are?
Take a simple concept that has worked interoperably and free for ages, add some marketing and proprietary lock-in: multi-billion dollar unicorn.
-
@topspin you missed the important killer feature though...
They're easy to use
-
@sloosecannon said in WTF Bites:
@topspin you missed the important killer feature though...
They're easy to use
Easy is whatever the last 5 things did
-
Marvel’s Avengers update flashes IP addresses on screen, dev promises fix
Bad news if you're a Twitch streamer on PS5, though dev says fix is incoming.
-
@sebastian-galczynski said in WTF Bites:
Many users would like to do transactions, but the lead dev, instead of implementing it, spends his time doing mental gymnastics
Just install an old version of MySQL.
Why?
Because it won't matter then anyway: in the old days, mysql did not support transactions.
That's the modern way to do things.
-
-
@BernieTheBernie said in WTF Bites:
@sebastian-galczynski said in WTF Bites:
Many users would like to do transactions, but the lead dev, instead of implementing it, spends his time doing mental gymnastics
Just install an old version of MySQL.
Why?
Because it won't matter then anyway: in the old days, mysql did not support transactions.
That's the modern way to do things.Although it's
that really, really old version did not have InnoDB, you would have to go before 2001 to find such version (pre-3.23 to be exact). It is somewhat muddled by the fact that the MyISAM was still the default for newly created tables, so people weren't even aware that there was a transaction support. I think the default changed to InnoDB at some point, but that was long, long after PostgreSQL performance issues were solved (thus removing the only reason for MySQL to be actually used).
-
@Kamil-Podlesak said in WTF Bites:
Actually, the main point makes sense - if you're writing AWS lambda (or something similar), you should not use transactions.
This is not about this kind of transactions (lasting between http requests etc). This is about the most trivial kind, like "insert one row, take db-generated id of that row and insert it somewhere else".
Things that Django, RoR, or fucking CakePHP does in transaction by default. Can't be done, because reasons.
-
@sebastian-galczynski said in WTF Bites:
@Kamil-Podlesak said in WTF Bites:
Actually, the main point makes sense - if you're writing AWS lambda (or something similar), you should not use transactions.
This is not about this kind of transactions (lasting between http requests etc). This is about the most trivial kind, like "insert one row, take db-generated id of that row and insert it somewhere else".
Things that Django, RoR, or fucking CakePHP does in transaction by default. Can't be done, because reasons.Because granularity is too fine, most likely. If you can has a connection to nearly any rdbms, you can have a very basic transaction as long as the transaction doesn't need to cross db connections.
-
We have this check to maintain data integrity when you have a required relation without cascade delete on the underlying database. It will also be needed for Mongo soon.
-
@sebastian-galczynski said in WTF Bites:
We have this check to maintain data integrity when you have a required relation without cascade delete on the underlying database. It will also be needed for Mongo soon.
Why are you even using an ORM of weight? Either it makes a compelling case or maybe you don't need one.
-
@Gribnit
This part of the project (other parts are in fact much more complex and actually require scalability) consists of a lot of highly customizable CRUD, and the frontend devs decided to use GraphQL this time (last time we used hydra and it wasn't great). They found the apollo + prisma stack and liked it at first glance, but not being experts in dealing with the database, they asked me for some feedback.Some ORM is definitely needed for this, unless you have free man-hours for writing raw queries.
-
@sebastian-galczynski said in WTF Bites:
Some ORM is definitely needed for this, unless you have free man-hours for writing raw queries.
The queries that an ORM is good at writing (basic fetch-all-the-fields or store-all-the-fields) are the queries that it's also pretty easy to write yourself. The queries that take hours of careful thought to compose are also the ones where the ORM either gives up or produces something absolutely horrible.
At least in my experience. But then I'm pretty happy writing SQL.
-
-
@sebastian-galczynski said in WTF Bites:
Some ORM is definitely needed for this, unless you have free man-hours for writing raw queries.
The queries that an ORM is good at writing (basic fetch-all-the-fields or store-all-the-fields) are the queries that it's also pretty easy to write yourself. The queries that take hours of careful thought to compose are also the ones where the ORM either gives up or produces something absolutely horrible.
At least in my experience. But then I'm pretty happy writing SQL.
I'd also +1 this, with a caveat that Entity Framework Core (the .NET Core/.NET 5+ compatible rewrite of Entity Framework) tends more toward explicitly throwing its hands up and telling you it can't, rather than just producing something absolutely horrible.
As to whether or not that's a good thing depends on whether you're dealing with greenfield queries or trying to mass-upgrade an existing system. Upgrades can be quite eye-opening when all of your reporting LINQ suddenly starts throwing EF exceptions.
-
@sebastian-galczynski said in WTF Bites:
Some ORM is definitely needed for this, unless you have free man-hours for writing raw queries.
The queries that an ORM is good at writing (basic fetch-all-the-fields or store-all-the-fields) are the queries that it's also pretty easy to write yourself. The queries that take hours of careful thought to compose are also the ones where the ORM either gives up or produces something absolutely horrible.
At least in my experience. But then I'm pretty happy writing SQL.
I'd also +1 this, with a caveat that Entity Framework Core (the .NET Core/.NET 5+ compatible rewrite of Entity Framework) tends more toward explicitly throwing its hands up and telling you it can't, rather than just producing something absolutely horrible.
As to whether or not that's a good thing depends on whether you're dealing with greenfield queries or trying to mass-upgrade an existing system. Upgrades can be quite eye-opening when all of your reporting LINQ suddenly starts throwing EF exceptions.
Hibernate is great at getting massive bugs into production. With lazy materialization it can even get through naive inspection! Then bam, query in loop.
But when the needful is done to fix that, suddenly it's crashing OOM! They don't understand, the needful eager was done, if lazily.
-
The queries that an ORM is good at writing (basic fetch-all-the-fields or store-all-the-fields) are the queries that it's also pretty easy to write yourself.
They're easy, but tedious (especially all that mapping, deduplicating joined results etc) and hard to maintain. You add a column somewhere and now have to fix it in 10 places. I've already run into this problem, in some other microservices written in python using raw psycopg.
-
Hibernate is great at getting massive bugs into production. With lazy materialization it can even get through naive inspection! Then bam, query in loop.
But when the needful is done to fix that, suddenly it's crashing OOM! They don't understand, the needful eager was done, if lazily.Don't know about the original Hibernate, but Doctrine has similar problems when the entity pointed to by a foreign key is polymorphic, because the type information is in the target table, not in the key, and objects can't change type at runtime. So it must always be loaded. There's really no solution for that if you want both strong typing and 3NF.
But I have a trick: you just left join the unneeded entities with an additional "1=0" condition, so that there are only NULLs to map, so no OOM.
-
@sebastian-galczynski said in WTF Bites:
deduplicating joined results
Has there been any progress towards returning nested result sets / structured data in "standard" SQL? Without going through XML?
Or is that more of an object database kind of thing?
-
@Zecc nested structures are fundamentally incompatible with the idea behind relational databases. There's a reason 1NF requires primitive, atomic values in every column.
-
Has there been any progress towards returning nested result sets / structured data in "standard" SQL? Without going through XML?
Or is that more of an object database kind of thing?I assume you wouldn't take going through JSON as an acceptable alternative.
When dealing with that sort of thing, you'll often extract key facts into the relational part and keep the rest as a raw chunk of data, in practice duplicating the data but so easy to do. If you still need to look inside the non-relational part, there'll be functions to do the work for you. But relational databases aren't typically really well set up for dealing with recursive data; you can do it with a self-join (and thinking about what question you're really asking) but it remains tricky.
Of course, none of this is the Worst Of The Worst. That's reserved for when you have two (or more) data models talking about the same thing that use Almost But Not Quite the same terms. Remapping that sort of thing is just awful and very brain-bending.
-
@Zecc nested structures are fundamentally incompatible with the idea behind relational databases. There's a reason 1NF requires primitive, atomic values in every column.
I'm talking about query results here.
-
@dkf The queries that take hours of careful thought to compose are also the ones where the ORM either gives up or produces something absolutely horrible.
Yeah I mostly agree with this. We use Hibernate at work, and several places in our code have native SQL queries where the ORM gave up.
But an ORM does provide some value, even given that.
- It covers you off from database dialect differences. Most DBs have similar SQL extensions these days but basic stuff like TOP/LMIIT is still done in incompatible ways.
- It allows you to marshal and unmarshal from/to domain objects, so only your DAL has to care about the database and you don't have to write that marshalling yourself.
- Although we don't do this, the ability to have a DB generated from code can be great in a greenfield project, and prevents duplication of effort in the DB schema and domain classes.
I like to step outside the ORM where it helps, and any full stack developer should know how to write SQL. But I'd still recommend using an ORM for the simple stuff.
-
@bobjanova said in WTF Bites:
It covers you off from database dialect differences.
This is the least useful "feature". In quotes, because in practice you can't switch the database without at least some tweaks, except in most trivial projects. In fact, I would rather sacrifice this 'backend-agnosticity' for more features, like support for the DISTINCT ON clause or window functions. Nobody will suddenly switch from postgres to mongodb, thousands of people need to break out to raw sql to do the trivial 'last address of the employee with the highest salary' case.
-
@bobjanova said in WTF Bites:
It covers you off from database dialect differences.
All my critical bits and pieces are absolutely locked to a single possible database. Migrating would be both a massive headache (some critical queries are very non-trivial) and a total ball-ache. I also have experience with the key alternatives and really don't like them for how they work in prod.
Don't use Derby. Just don't. SQLite has its quirks, but works so much better. (Not needing a DB server is useful for the application domain.)
-
@sebastian-galczynski said in WTF Bites:
This is the least useful "feature". In quotes, because in practice you can't switch the database without at least some tweaks, except in most trivial projects
This may be the case for your project but it isn't the case for everyone. In fact, our (non trivial, real world) application does in fact have to support four different SQL RDBMSs, and so that feature is really useful for us.
Obviously if none of those three features of an ORM is useful for your project then consider not using them. But they are all real world use cases for someone.
Nobody will suddenly switch from postgres to mongodb
Most ORMs wouldn't deal with that anyway. But they may switch from MySQL to Postgres, or to SQL Server (well, more realistically, different customers of the same application may be on each).
-
@Zecc Standard SQL has composite types: arrays (which are what they sound like) and rows (which are the sort of thing you can think of tables as being lists of). You can store and work with them within the database, but when they're serialised into query results they typically end up being strings. Then again, if you think of that as a wire protocol you'd be parsing that application-side into structured data. But try finding an ORM that does that.
-
@loopback0 said in WTF Bites:
@BernieTheBernie said in WTF Bites:
Just install an old version of MySQL.
Bad ideas is
Guess what, we have a team of devs that have been given a dedicated, old MySQL instance (that we have to fix every couple of days because something they do keeps fucking up the brittle master-master replication) because in 2021 they're still using tables without primary keys so their shit won't work with Galera cluster. Ops has been nagging them for the better part of a decade but now the constant breakage seems to have convinced some higher-ups they need their asses kicked to finally fix that.
Here's the proposed fix (table names edited to protect the guilty):ALTER TABLE table1 ADD id_pk INT PRIMARY KEY AUTO_INCREMENT; ALTER TABLE table2 ADD id_pk INT PRIMARY KEY AUTO_INCREMENT; ALTER TABLE table3 ADD id_pk INT PRIMARY KEY AUTO_INCREMENT; ALTER TABLE table4 ADD id_pk INT PRIMARY KEY AUTO_INCREMENT; ALTER TABLE table5 ADD id_pk INT PRIMARY KEY AUTO_INCREMENT; ALTER TABLE table6 ADD id_pk INT PRIMARY KEY AUTO_INCREMENT;I know what you're thinking, and you're right: this looks
suboptimalfucking stupid.
It fits right in with how the table looks right now though:CREATE TABLE `table1` ( `foo_id` bigint(20) NOT NULL, `bar_id` bigint(20) NOT NULL, UNIQUE KEY `bar_id` (`bar_id`), UNIQUE KEY `UK_6q3rdsbfadhkjhjgj8p1lseau` (`bar_id`), KEY `FKECE96743FF36569A` (`foo_id`), KEY `FKECE96743FF3BE15D` (`bar_id`), CONSTRAINT `FKECE91D4D3336569A` FOREIGN KEY (`foo_id`) REFERENCES `Principals` (`id`), CONSTRAINT `FKECE91D4DD53BE15D` FOREIGN KEY (`bar_id`) REFERENCES `ContextEntity` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;At least it's not MyISAM.
-
Autoincrement IDs are fine, unless you're paranoid about website scraping by iterating on ids.
CREATE TABLE
table1(
foo_idbigint(20) NOT NULL,
bar_idbigint(20) NOT NULL,
UNIQUE KEYbar_id(bar_id),
UNIQUE KEYUK_6q3rdsbfadhkjhjgj8p1lseau(bar_id),Wait what? What's the purpose of this table? It's not many-to-many (that would have one unique key on both columns), it's like an optional many-to-one. But then why there is a table, when a column in foo would be enough?
-
@sebastian-galczynski said in WTF Bites:
Autoincrement IDs are fine, unless you're paranoid about website scraping by iterating on ids.
They wouldn't even use them, they're just adding an extra column "because it wants a key". Instead of, you know, looking at what their data is like.
CREATE TABLE
table1(
foo_idbigint(20) NOT NULL,
bar_idbigint(20) NOT NULL,
UNIQUE KEYbar_id(bar_id),
UNIQUE KEYUK_6q3rdsbfadhkjhjgj8p1lseau(bar_id),Wait what? What's the purpose of this table? It's not many-to-many (that would have one unique key on both columns), it's like an optional many-to-one. But then why there is a table, when a column in foo would be enough?
It is indeed meant as a many-to-many, but for some reason that I'm sure not even the developers themselves can explain, half of it is in a column in ContextEntity. My guess is they had that column already before they noticed they need to navigate that relationship bidirectionally so they just added this thing. With three indices on the same column, just to be safe.
-
-
@TimeBandit said in WTF Bites:
DEFAULT CHARSET=latin1;
Yes, there's hardly anything about that database design that's not a WTF.
-
-
@Zecc nested structures are fundamentally incompatible with the idea behind relational databases. There's a reason 1NF requires primitive, atomic values in every column.
I'm talking about query results here.
In SQL, query is a transformation of relations inside DB according to rules of relational algebra. Conceptually there is no difference between data format of a table and a data format of a result - both are just sets of tuples. And it's important there isn't because it means subqueries work 100% identical to queries (in practice not really but it's a bad thing that they don't).
-
@TimeBandit said in WTF Bites:
DEFAULT CHARSET=latin1;The MySQL default until 8.0 came out just three years ago.
-
@Zerosquare said in WTF Bites:
@TimeBandit said in WTF Bites:
DEFAULT CHARSET=latin1;
Spics are cool like this, must be all the beans.
-
The queries that an ORM is good at writing (basic fetch-all-the-fields or store-all-the-fields) are the queries that it's also pretty easy to write yourself.
Except they're major PITAs to maintain (I know someone already made this point but I don't think it can be emphasized enough).
They also make things so much easier for our new REST + Angular architecture. I can make a DTO object to pull up just the stuff I need that's mostly a copy* of the actual domain object. So I don't have to do tons of querying and creating and hydrating objects to send to the browser. Hibernate does most of the work for me.
* Our "normal" objects have lots of lazily loaded references, plus objects that refer to each other via annotations (so a "child" object could know which parent it belongs to). Plus, Hibernate uses a cache so it doesn't try to reload stuff like that. But a naive serialization to JSON causes infinite recursion back and forth between the two. Anyways, if I had to build all that shit by hand it would be a nightmare of tedium and broken shit whenever something changes and we forget to update the translation from the DB.
-
@boomzilla said in WTF Bites:
The queries that an ORM is good at writing (basic fetch-all-the-fields or store-all-the-fields) are the queries that it's also pretty easy to write yourself.
Except they're major PITAs to maintain (I know someone already made this point but I don't think it can be emphasized enough).
They also make things so much easier for our new REST + Angular architecture. I can make a DTO object to pull up just the stuff I need that's mostly a copy* of the actual domain object. So I don't have to do tons of querying and creating and hydrating objects to send to the browser. Hibernate does most of the work for me.
* Our "normal" objects have lots of lazily loaded references, plus objects that refer to each other via annotations (so a "child" object could know which parent it belongs to). Plus, Hibernate uses a cache so it doesn't try to reload stuff like that. But a naive serialization to JSON causes infinite recursion back and forth between the two. Anyways, if I had to build all that shit by hand it would be a nightmare of tedium and broken shit whenever something changes and we forget to update the translation from the DB.
Good thing you don't have sufficient monitoring to understand what it's doing...
-
@sebastian-galczynski said in WTF Bites:
@bobjanova said in WTF Bites:
It covers you off from database dialect differences.
This is the least useful "feature". In quotes, because in practice you can't switch the database without at least some tweaks, except in most trivial projects. In fact, I would rather sacrifice this 'backend-agnosticity' for more features, like support for the DISTINCT ON clause or window functions. Nobody will suddenly switch from postgres to mongodb, thousands of people need to break out to raw sql to do the trivial 'last address of the employee with the highest salary' case.
Heh...occasionally someone around here brings that up and I'm always quick to shut it down. Would be a total nightmare to get it to run on anything but Oracle at this point.
-
@boomzilla said in WTF Bites:
The queries that an ORM is good at writing (basic fetch-all-the-fields or store-all-the-fields) are the queries that it's also pretty easy to write yourself.
Except they're major PITAs to maintain (I know someone already made this point but I don't think it can be emphasized enough).
They also make things so much easier for our new REST + Angular architecture. I can make a DTO object to pull up just the stuff I need that's mostly a copy* of the actual domain object. So I don't have to do tons of querying and creating and hydrating objects to send to the browser. Hibernate does most of the work for me.
* Our "normal" objects have lots of lazily loaded references, plus objects that refer to each other via annotations (so a "child" object could know which parent it belongs to). Plus, Hibernate uses a cache so it doesn't try to reload stuff like that. But a naive serialization to JSON causes infinite recursion back and forth between the two. Anyways, if I had to build all that shit by hand it would be a nightmare of tedium and broken shit whenever something changes and we forget to update the translation from the DB.
Good thing you don't have sufficient monitoring to understand what it's doing...
I've watched what it does. Why do you think:
- that I haven't
- that it's a problem
I've stated before around that sometimes I do drop to native SQL and manually convert the objects when either the query is too complicated or for other performance reasons.
It sounds like you're telling me I need to prematurely optimize stuff that works just fine. But I suspect you'll now deny that.
-
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
The queries that an ORM is good at writing (basic fetch-all-the-fields or store-all-the-fields) are the queries that it's also pretty easy to write yourself.
Except they're major PITAs to maintain (I know someone already made this point but I don't think it can be emphasized enough).
They also make things so much easier for our new REST + Angular architecture. I can make a DTO object to pull up just the stuff I need that's mostly a copy* of the actual domain object. So I don't have to do tons of querying and creating and hydrating objects to send to the browser. Hibernate does most of the work for me.
* Our "normal" objects have lots of lazily loaded references, plus objects that refer to each other via annotations (so a "child" object could know which parent it belongs to). Plus, Hibernate uses a cache so it doesn't try to reload stuff like that. But a naive serialization to JSON causes infinite recursion back and forth between the two. Anyways, if I had to build all that shit by hand it would be a nightmare of tedium and broken shit whenever something changes and we forget to update the translation from the DB.
Good thing you don't have sufficient monitoring to understand what it's doing...
I've watched what it does. Why do you think:
- that I haven't
- that it's a problem
I've stated before around that sometimes I do drop to native SQL and manually convert the objects when either the query is too complicated or for other performance reasons.
It sounds like you're telling me I need to prematurely optimize stuff that works just fine. But I suspect you'll now deny that.
The kind of damage lazy materialization yields is a bit subtle. Since you resist change so strongly it is assumable you have insufficient monitoring to see it. The fact that you confuse monitoring with optimization confirms this. So you also have no instrumentation.
Since you are obtuse, the issue is that a lazily materialized collection may very well also be the basis for a call or series of calls to another system. When that system is slow, the connection H is using under the table is held open maybe 100x longer than expected. This creates conditions that can exhaust db connections. Even without this, it's still hidden query-in-loop.
I begin to suspect you don't know that's an antipattern though.
-
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
The queries that an ORM is good at writing (basic fetch-all-the-fields or store-all-the-fields) are the queries that it's also pretty easy to write yourself.
Except they're major PITAs to maintain (I know someone already made this point but I don't think it can be emphasized enough).
They also make things so much easier for our new REST + Angular architecture. I can make a DTO object to pull up just the stuff I need that's mostly a copy* of the actual domain object. So I don't have to do tons of querying and creating and hydrating objects to send to the browser. Hibernate does most of the work for me.
* Our "normal" objects have lots of lazily loaded references, plus objects that refer to each other via annotations (so a "child" object could know which parent it belongs to). Plus, Hibernate uses a cache so it doesn't try to reload stuff like that. But a naive serialization to JSON causes infinite recursion back and forth between the two. Anyways, if I had to build all that shit by hand it would be a nightmare of tedium and broken shit whenever something changes and we forget to update the translation from the DB.
Good thing you don't have sufficient monitoring to understand what it's doing...
I've watched what it does. Why do you think:
- that I haven't
- that it's a problem
I've stated before around that sometimes I do drop to native SQL and manually convert the objects when either the query is too complicated or for other performance reasons.
It sounds like you're telling me I need to prematurely optimize stuff that works just fine. But I suspect you'll now deny that.
The kind of damage lazy materialization yields is a bit subtle.
Such as?
Since you resist change so strongly it is assumable you have insufficient monitoring to see it. The fact that you confuse monitoring with optimization confirms this. So you also have no instrumentation.
You must have me confused with someone else. None of that applies to me or my situation, but it would be
amusingtedious to hear why you think it does.
-
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
The queries that an ORM is good at writing (basic fetch-all-the-fields or store-all-the-fields) are the queries that it's also pretty easy to write yourself.
Except they're major PITAs to maintain (I know someone already made this point but I don't think it can be emphasized enough).
They also make things so much easier for our new REST + Angular architecture. I can make a DTO object to pull up just the stuff I need that's mostly a copy* of the actual domain object. So I don't have to do tons of querying and creating and hydrating objects to send to the browser. Hibernate does most of the work for me.
* Our "normal" objects have lots of lazily loaded references, plus objects that refer to each other via annotations (so a "child" object could know which parent it belongs to). Plus, Hibernate uses a cache so it doesn't try to reload stuff like that. But a naive serialization to JSON causes infinite recursion back and forth between the two. Anyways, if I had to build all that shit by hand it would be a nightmare of tedium and broken shit whenever something changes and we forget to update the translation from the DB.
Good thing you don't have sufficient monitoring to understand what it's doing...
I've watched what it does. Why do you think:
- that I haven't
- that it's a problem
I've stated before around that sometimes I do drop to native SQL and manually convert the objects when either the query is too complicated or for other performance reasons.
It sounds like you're telling me I need to prematurely optimize stuff that works just fine. But I suspect you'll now deny that.
The kind of damage lazy materialization yields is a bit subtle.
Such as?
Since you resist change so strongly it is assumable you have insufficient monitoring to see it. The fact that you confuse monitoring with optimization confirms this. So you also have no instrumentation.
You must have me confused with someone else. None of that applies to me or my situation, but it would be
amusingtedious to hear why you think it does.It would be surprising for someone demonstrating your specific incompetences to be able to use tools effectively. You take easy answers you like by preference. That's not salutary.
-
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
The queries that an ORM is good at writing (basic fetch-all-the-fields or store-all-the-fields) are the queries that it's also pretty easy to write yourself.
Except they're major PITAs to maintain (I know someone already made this point but I don't think it can be emphasized enough).
They also make things so much easier for our new REST + Angular architecture. I can make a DTO object to pull up just the stuff I need that's mostly a copy* of the actual domain object. So I don't have to do tons of querying and creating and hydrating objects to send to the browser. Hibernate does most of the work for me.
* Our "normal" objects have lots of lazily loaded references, plus objects that refer to each other via annotations (so a "child" object could know which parent it belongs to). Plus, Hibernate uses a cache so it doesn't try to reload stuff like that. But a naive serialization to JSON causes infinite recursion back and forth between the two. Anyways, if I had to build all that shit by hand it would be a nightmare of tedium and broken shit whenever something changes and we forget to update the translation from the DB.
Good thing you don't have sufficient monitoring to understand what it's doing...
I've watched what it does. Why do you think:
- that I haven't
- that it's a problem
I've stated before around that sometimes I do drop to native SQL and manually convert the objects when either the query is too complicated or for other performance reasons.
It sounds like you're telling me I need to prematurely optimize stuff that works just fine. But I suspect you'll now deny that.
The kind of damage lazy materialization yields is a bit subtle.
Such as?
Since you resist change so strongly it is assumable you have insufficient monitoring to see it. The fact that you confuse monitoring with optimization confirms this. So you also have no instrumentation.
You must have me confused with someone else. None of that applies to me or my situation, but it would be
amusingtedious to hear why you think it does.It would be surprising for someone demonstrating your specific incompetences to be able to use tools effectively. You take easy answers you like by preference. That's not salutary.
Fine. Don't be responsive or informative. I guess that's what I deserve for engaging you in good faith outside the garage.
-
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
@boomzilla said in WTF Bites:
The queries that an ORM is good at writing (basic fetch-all-the-fields or store-all-the-fields) are the queries that it's also pretty easy to write yourself.
Except they're major PITAs to maintain (I know someone already made this point but I don't think it can be emphasized enough).
They also make things so much easier for our new REST + Angular architecture. I can make a DTO object to pull up just the stuff I need that's mostly a copy* of the actual domain object. So I don't have to do tons of querying and creating and hydrating objects to send to the browser. Hibernate does most of the work for me.
* Our "normal" objects have lots of lazily loaded references, plus objects that refer to each other via annotations (so a "child" object could know which parent it belongs to). Plus, Hibernate uses a cache so it doesn't try to reload stuff like that. But a naive serialization to JSON causes infinite recursion back and forth between the two. Anyways, if I had to build all that shit by hand it would be a nightmare of tedium and broken shit whenever something changes and we forget to update the translation from the DB.
Good thing you don't have sufficient monitoring to understand what it's doing...
I've watched what it does. Why do you think:
- that I haven't
- that it's a problem
I've stated before around that sometimes I do drop to native SQL and manually convert the objects when either the query is too complicated or for other performance reasons.
It sounds like you're telling me I need to prematurely optimize stuff that works just fine. But I suspect you'll now deny that.
The kind of damage lazy materialization yields is a bit subtle.
Such as?
Since you resist change so strongly it is assumable you have insufficient monitoring to see it. The fact that you confuse monitoring with optimization confirms this. So you also have no instrumentation.
You must have me confused with someone else. None of that applies to me or my situation, but it would be
amusingtedious to hear why you think it does.It would be surprising for someone demonstrating your specific incompetences to be able to use tools effectively. You take easy answers you like by preference. That's not salutary.
Fine. Don't be responsive or informative. I guess that's what I deserve for engaging you in good faith outside the garage.
So little patience. And a paucity of good faith, doesn't tip the scales.
You've been wilting yourself in a hothouse, the purge of opinion has let you get lazy, and rather entitled.
In other news, the prior was meant entirely seriously, vs as a mere insult.
-
status Taking an online test for training materials
Da statement to evaluate.
True
False
None of the aboveHonest to $deity.
-
status Taking an online test for training materials
Da statement to evaluate.
True
False
None of the aboveHonest to $deity.
Maybe it's null.
-
status Taking an online test for training materials
Da statement to evaluate.
True
False
None of the aboveHonest to $deity.
Maybe it's null.
Maybe that's the answer I got wrong... (I got 9/10 - but they don't tell you which one was wrong)
