|
Markov Chain Chomp posted:The rule of thumb is to prefer more abstraction, not less, unless you have a very particular reason for doing so. The rule of thumb of a fresh college graduate.
|
#
?
Dec 10, 2011 03:04
|
|
|
|
| # ? May 14, 2024 12:45 |
|
|
Ithaqua posted:It saves time and effort. How many times have you written code that: Using Python's SqlSoup or Ruby's Sequel? Never.
|
|
#
?
Dec 10, 2011 03:10
|
|
|
shrughes posted:The rule of thumb of a fresh college graduate. Are you officially stalking me now
|
|
#
?
Dec 10, 2011 03:15
|
|
|
Markov Chain Chomp posted:There's literally no reason to be operating with your DB directly Markov Chain Chomp posted:Also, nothing forbids you from using both. But... but the goalposts  npe posted:I wasn't seriously advocating that it be used everywhere Nah, I didn't think you were. I'm sure it has its places -- I have seen it before, and it was on a moderately complex web app, and it was terrible, but everything in that codebase was some degree degrees of  so I've got lots of bad tastes in my mouth.
|
|
#
?
Dec 10, 2011 03:20
|
|
|
wwb posted:I'll also add it is possible to nest transactions. Not in MySQL.
|
|
#
?
Dec 10, 2011 03:35
|
|
|
Markov Chain Chomp posted:The rule of thumb is to prefer more abstraction, not less, unless you have a very particular reason for doing so. I hope you remember saying this ten years from now. You'll get a kick out of it.
|
|
#
?
Dec 10, 2011 03:41
|
|
|
Hammerite posted:Not in MySQL. Haha seriously? MySQL Reference posted:Transactions cannot be nested. This is a consequence of the implicit commit performed for any current transaction when you issue a START TRANSACTION statement or one of its synonyms. Transactions cannot be nested as a consequence of their inability to be nested 
|
|
#
?
Dec 10, 2011 04:04
|
|
|
Markov Chain Chomp posted:The rule of thumb is to prefer more abstraction, not less, unless you have a very particular reason for doing so. I apparently have very good particular reasons all the time, then. Furthermore, SQL is already an amazing abstraction. It completely takes out of the picture of how to store data and just lets you write "please insert this data, thanks". All an ORM does is let you pretend that tables are classes and rows are objects and columns are members. Not only are there cases when pretending things are objects is not OK, there are cases where ORMs do not provide the expressive power of raw SQL. Just like compiling from a high-level language to assembly restricts you to the subset of features that the high-level language has, compiling from an ORM's language to SQL restricts you to the subset of features that the ORM has. And because SQL is a unique language in that it lets you express what you want to do, not being bogged down by implementation details, you're cutting out a lot of features when you restrict yourself to an ORM's feature set. For simple CRUD operations, this is perfectly fine, but when you start wanting asking complex queries like "what's the average of all the star ratings that customer A, B and C for products they ordered in the last thirty days that shipped in under a week?", you start pushing the limits of the ORM. Yes, this was a real report that I implemented two weeks ago.
|
|
#
?
Dec 10, 2011 04:27
|
|
|
Hammerite posted:Not in MySQL. They do have transaction savepoints, which can be used for similar, though not identical purposes as nested transactions.
|
|
#
?
Dec 10, 2011 05:34
|
|
|
Suspicious Dish posted:I apparently have very good particular reasons all the time, then. code:NotShadowStar fucked around with this message at 08:02 on Dec 10, 2011 |
|
#
?
Dec 10, 2011 07:57
|
|
|
Suspicious Dish posted:And because SQL is a unique language in that it lets you express what you want to do, not being bogged down by implementation details. Ho boy, wait until you actually DO use a different database software than MySQL! Yeah sure, as long as you stick to simple select/update queries you will be fine, but if you ever get as far as set operations or the likes and switch between DB2/pgsql/mysql/whatever, you'll be poo poo out of luck.
|
|
#
?
Dec 10, 2011 10:51
|
|
|
wwb posted:Please use the 2nd answer. Works great For a second you got me all excited that Java had anonymous functions. Nope, C# 
|
|
#
?
Dec 10, 2011 11:39
|
|
|
NotShadowStar posted:
doesn't that do a simpler query and run the rest in the language? for aggregates I would imagine doing it in sql to be cheaper
|
|
#
?
Dec 10, 2011 12:09
|
|
|
I've yet to meet an ORM I liked, I've found them difficult to use to do aggregates, non-trivial joins, set operations, anything that looks like a CTE, self joins, atomic updates to multiple rows or do get the kind of fine grained control over transactions that I often need. Also this is way easier for me to read than NotShadowStar's ORM example. It's smaller too. code:
|
|
#
?
Dec 10, 2011 15:54
|
|
|
To get away from the ORM/SQL talk for a moment, let me share a gem from a file at work:php:<?
(some code here...)
$mysql = "Select [some stuff here] where username = '" . $user . "' AND password = '".$pass."'";
$result = mysql_query("$mysql");
$num_rows = mysql_num_rows($result);
if ($num_rows > 0){
$row = mysql_fetch_assoc($result);
$mylocarray = explode(",",$row['locations']);
foreach($mylocarray as $k) {
if ($k = $locationid) {
$goodtogo = 1;
}
}
mysql_free_result($result);
if (isset($locationid)) {
if ($goodtogo=1) {
$mysql = "select [more stuff here] where locationid = " . $locationid . " and idnum = " . $numid;
$result = mysql_query("$mysql");
$num_rows = mysql_num_rows($result);
if ($num_rows > 0){
/*
about 280 lines of similar code later...
*/
mysql_free_result($result3);
}
}
$xml_output .= "</results>\r\n";
echo $xml_output;
// END CODE FROM <some file>.php
}}}}}}
}// goodtogo = 1, locationid passed is available to the passed username/password
}// end of check to see if location id is passed
} // end of valid user/pass test and location return
} // end of is api command '<xxx>'
mysql_close($con);
} // End of is apifuncset
?>
?>I like to imagine that the line of }s at the end was just "let's see how many it takes to make this work", save, reload, add a }, repeat until page works. They also use $row=mysql_fetch_assoc($res); do { ... } while ($row=mysql_fetch_assoc($res)) which is all sorts of wrong. 
|
|
#
?
Dec 10, 2011 16:16
|
|
|
tef posted:doesn't that do a simpler query and run the rest in the language? for aggregates I would imagine doing it in sql to be cheaper I can do it entirely in SQL methods with AR but this would actually be cheaper since Ruby's Enumerable is written in C plus it was one in the morning and I'm posting on an internet comedy forum so gently caress haters.
|
|
#
?
Dec 10, 2011 16:54
|
|
|
I use EODSQL at work instead of a normal ORM. You write your own SQL but it deals with all the boilerplate crap like marshalling to and from SQL types, binding parameters, etc. Best of both worlds if you prefer to write your own SQL.
|
|
#
?
Dec 10, 2011 17:05
|
|
|
NotShadowStar posted:this would actually be cheaper since Ruby's Enumerable is written in C Might be more expensive since any rows not returned by the DB don't have to be sent over the network.
|
|
#
?
Dec 10, 2011 18:18
|
|
|
Demanding SQL only though an ORM is the coding horror. Even basic CRUD apps break down with ORMs when you have a sizable data set. Temp tables can do a lot to help performance on simple queries on large amounts of data, even in cases where you're only using a couple joins. Let me know when you find an ORM that does that optimization for you.
|
|
#
?
Dec 10, 2011 18:53
|
|
|
NotShadowStar posted:
In order to avoid sql you'd write all this? This is probably an order of magnitude slower than just writing the SQL.
|
|
#
?
Dec 10, 2011 19:05
|
|
|
McGlockenshire posted:They do have transaction savepoints, which can be used for similar, though not identical purposes as nested transactions. I had no idea about this, thanks for pointing it out to me.
|
|
#
?
Dec 10, 2011 19:21
|
|
|
TRex EaterofCars posted:In order to avoid sql you'd write all this? This is probably an order of magnitude slower than just writing the SQL. Point out where anybody said speed or efficiency, that was a response to 'you just can't do it'. Good lord for being sperg kingdom you guys sure do miss details.
|
|
#
?
Dec 10, 2011 19:28
|
|
|
NotShadowStar posted:Point out where anybody said speed or efficiency, that was a response to 'you just can't do it'. *writes code that could take days to complete when displaying a web page* *complains that "You never said it had to be fast"*
|
|
#
?
Dec 10, 2011 19:43
|
|
|
Zombywuf posted:*writes code that could take days to complete when displaying a web page* *posts piles of hyperbole
|
|
#
?
Dec 10, 2011 20:17
|
|
|
a quick recap for those who haven't been reading the threadquote:when you start wanting asking complex queries [...] , you start pushing the limits of the ORM. Pushing the limits. No-one said it had to be fast explicitly, but the implication was that orms have limitations and sometimes you must use sql. speed is one of those mitigating factors in choosing to use sql over an orm. Your 'it can be done in an orm  ' was a facile statement beside the point. orms can model a large chunk of things. we know this. however it turns out there are tradeoffs, like performance,e that are not made in your favour.If you're going to contribute with your deadly wit and canny ripostes, it would help if we didn't have to explain all the words in the post you're replying to.  also, 'ruby is written in c so it's fast' 
|
|
#
?
Dec 10, 2011 21:04
|
|
|
.
|
|
#
?
Dec 10, 2011 21:14
|
|
|
tef posted:also, 'ruby is written in c so it's fast' Boy, just imagine if it was written in hand-rolled assembly.
|
|
#
?
Dec 10, 2011 21:19
|
|
|
tef posted:also, 'ruby is written in c so it's fast' ruby + mysql via orm, the fastest way to write your web three point blah apps for
|
|
#
?
Dec 10, 2011 22:58
|
|
|
tef posted:also, 'ruby is written in c so it's fast' I know what you're poking fun at here, but taking a slightly different (and I think complementary) tack: The database is written in C, and it's fast. Even lovely databases like MySQL have had a ton of work done to make them fast, especially for common cases, often by very smart people with lots of domain experience who were being paid to do nothing but make the database faster. Beating the database's query optimizer or whatever by manually specifying a bunch of poo poo is generally not something to try your hand at if you don't have a good reason (although it's not as quixotic as trying to beat the compiler's register allocator*), and you're almost certainly not going to beat it by handing off a bunch of operations to your ORM layer (which will abuse the database by pretending it's a flat file or some other poo poo frighteningly often). This isn't to say that ORMs aren't useful, but rather that it's misleading to say that moving work to that layer instead of the DB is 'fast'. Performance statements are always in comparison to something else; letting the ORM do most of the work may (or may not) be 'fast' in comparison to the minimum acceptable level of performance for your application at the problem size you expect to encounter, but it probably isn't 'fast' in comparison to letting the DB do what it was designed to do. *there are specific cases where even this usually thankless task pays off, usually in the realm of vectorized code
|
|
#
?
Dec 11, 2011 00:20
|
|
|
Found this poking around one of our business objects, trying to figure out why putting a single white space in a text field was crashing an lob web appcode:For even more fun, the calling site of getParam is on the page hosting the user control. Entire goddamn 100+ user site is written like this, and worse. The contractor who wrote most of this was offered a position but turned it down - they didn't offer enough money. edit - Almost forgot, the getParam has to pull some vital peice of information about the current work. What's the best way to pull it, considering we already queried the database in a seperate page? I know! var theValue = ((Label)Page.Master.Master.Master.FindControl("xxx").FindControl("xxx").FindControl("xxx").FindControl("xxx").FindControl(someLabel)).Text; Atimo fucked around with this message at 04:17 on Dec 11, 2011 |
|
#
?
Dec 11, 2011 04:04
|
|
|
Otto Skorzeny posted:I know what you're poking fun at here, but taking a slightly different (and I think complementary) tack: I am fully expecting not shadow star to reply to this post with a thoughtful ruby snippet.
|
|
#
?
Dec 11, 2011 05:30
|
|
|
tef posted:I am fully expecting not shadow star to reply to this post with a thoughtful ruby snippet. What the gently caress is your problem?
|
|
#
?
Dec 11, 2011 08:11
|
|
|
NotShadowStar posted:What the gently caress is your problem? NotShadowStar posted:this would actually be cheaper since Ruby's Enumerable is written in C
|
|
#
?
Dec 11, 2011 08:57
|
|
|
tef posted:a quick recap for those who haven't been reading the thread Are you daft, tef? Any decent ORM would turn that given example into exactly the same SQL that a human would write (although not if you tried to write it the way notshadowstar did). And with a good JIT the differences would disappear outright. Maybe you ought to step out of the world of turtles and into the modern era. 
|
|
#
?
Dec 11, 2011 09:33
|
|
|
For reference, here's a code snippet from one ORM[1] which makes quick work out of that examplecode:[1] Django Project, The. https://github.com/django/django/blob/master/django/db/models/sql/aggregates.py .
|
|
#
?
Dec 11, 2011 09:46
|
|
|
The Something Awful Forums > Discussion > Serious Hardware / Software Crap > The Cavern of COBOL > Coding horrors: post the code that makes you laugh (or cry) > Spergin' on the ORM OTOH, I horrify myself daily. code:
|
|
#
?
Dec 11, 2011 10:03
|
|
|
Markov Chain Chomp posted:Are you daft, tef? Any decent ORM would turn that given example into exactly the same SQL that a human would write (although not if you tried to write it the way notshadowstar did). And with a good JIT the differences would disappear outright. Maybe you ought to step out of the world of turtles and into the modern era. tl;dr SQL isn't hard, use it
|
|
#
?
Dec 11, 2011 10:13
|
|
|
Markov Chain Chomp posted:For reference, here's a code snippet from one ORM[1] which makes quick work out of that example How would you do this with an ORM? code:
|
|
#
?
Dec 11, 2011 12:37
|
|
|
Markov Chain Chomp posted:Are you daft, tef? Yup. Which is why I asked the first time if it was the case - I wasn't sure if the ORM could map it. I didn't think the original example was the best to show the limitations of orm. tef fucked around with this message at 13:56 on Dec 11, 2011 |
|
#
?
Dec 11, 2011 13:52
|
|
|
|
| # ? May 14, 2024 12:45 |
|
|
NotShadowStar posted:What the gently caress is your problem? To quote someone else ”I’m posting on an internet comedy forum so gently caress haters.”. I just feel that as a resident of sperg kingdom I shouldn't miss the details of making GBS threads all over your posts. Brecht posted:You are the coding horror. Hell is other peoples code. We are all the horror.
|
|
#
?
Dec 11, 2011 13:54
|
|