p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

Shaggar: Apr 26, 2006

one of the things sql server needs is built in schema versioning. it seems like the most obvious thing but its not there because who knows why?!?

# ? Aug 10, 2014 03:44

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 13:26

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

i bet in real codebases using mybatis people still just od inline sql

# ? Aug 10, 2014 03:45

Shaggar: Apr 26, 2006

haha, actually I do know why. I asked a guy on the vs team why sql server doesn't have that and his response was that im supposed to do it in visual studio and I said that was stupid cause vs's db tools suck and also db schema doesn't fit vs's solution model but he (and apparently Microsoft) think people are still writing siloed apps like its the 80s or something.

# ? Aug 10, 2014 03:46

Stringent: Dec 22, 2004; image text goes here

Shaggar posted:

one of the things sql server needs is built in schema versioning. it seems like the most obvious thing but its not there because who knows why?!?

just use postgresql instead

# ? Aug 10, 2014 03:46

Shaggar: Apr 26, 2006

USSMICHELLEBACHMAN posted:

i bet in real codebases using mybatis people still just od inline sql

yeah there are probably terrible developers in lots of codebases

# ? Aug 10, 2014 03:47

americong: May 29, 2013

why in the gently caress is a key language feature tied to a specific ide

# ? Aug 10, 2014 03:57

Mr. Glass: May 1, 2009

americong posted:

why in the gently caress is a key language feature tied to a specific ide

because microsoft

# ? Aug 10, 2014 04:03

Soricidus: Oct 21, 2010; freedom-hating statist shill

americong posted:

why in the gently caress is a key language feature tied to a specific ide

why the gently caress would you use any microsoft technology ever if you don't want vendor lock-in forcing you to use all microsoft technologies? that's kind of their whole thing.

if you want a free competitive environment where you can pick and mix products from a variety of sources, try java.

# ? Aug 10, 2014 10:58

Stringent: Dec 22, 2004; image text goes here

i wish Swift was usable as a general purpose language...

# ? Aug 10, 2014 11:24

Sapozhnik: Jan 2, 2005; Nap Ghost

Shaggar posted:

if I weren't insanely lazy I would write that proc -> soap method thing cause it would be super easy

I wrote a Java thing that takes the Class of an interface that has some of ur db's stored procs as methods and gives you back a proxy object that you can invoke those methods on and they get mapped to SP calls through the magic of reflection

and another thing that takes a Class representing a row in a view and gives you back an object that can execute queries on that view for you, including building some basic WHERE and ORDER BY clauses from the supplied parameters

it really owns

# ? Aug 10, 2014 11:30

tef: May 30, 2004; -> some l-system crap ->

Subjunctive posted:

recreational full table scans

# ? Aug 10, 2014 12:22

havelock: Jan 20, 2004; IGNORE ME; Soiled Meat

Stored procs (and statement mappers) don't compose.

You have to choose between fetching too much data (and then filtering/sorting/projecting in memory) or leaking database details through all your layers. An abstract criteria API handles some of this in a not-too-icky sort of way, but looks awfully primitive when compared to IQueryable. With Queryables at your layer boundaries, each component can filter/project/refine however it needs to and still (generally speaking) have everything collapse to a reasonable sql query. Plus you can easily test each layer in isolation using List<T>s or something.

The composition/abstraction benefits far outweigh the costs of the very slightly leaky abstraction (i.e., small amount of thinking required to not generate horribly queries).

# ? Aug 10, 2014 14:03

Sapozhnik: Jan 2, 2005; Nap Ghost

You're right, but not for the reasons you've given.

In an ooplang you're ultimately going to have something that looks a lot like a data access object with methods that take some parameters and spit out records (or maybe a scalar result or nothing at all). If you enjoy pain then you can implement this DAO using JDBC in Java or whatever. If you're smart like me then you'll write a SP in a language designed for doing inline SQL poo poo i.e. plPG/SQL (lol if you actually choose to use MySQL, smh)

The first problem with this approach is that arguably the lifecycle of these SPs is more closely tied to each particular application than it is to the db itself, so you end up doing more database releases than you'd strictly need to, and db releases are a pain. Don't ever have your application perform automatic schema changes at startup btw, that is some seriously plang-tier poo poo. Unless you're using an embedded SQLite or something but that doesn't count.

The bigger problem is that the division of responsibilities is a complete and utter lie. The db is supposed to handle "data integrity" and the application tier is supposed to handle access control and "business logic", but these are both very slippery concepts and you need to know some business logic in order to validate your data even at a structural level. So you still end up with a bit of a soup.

Also it's incredibly hard to design a minimal and orthogonal set of stored procs that don't over-fetch from the db, like you said.

Interfacing with relational databases is a pain, but there's a lot of essential complexity that's clouded by the accidental complexity of SQL's general shittiness, and things like ORMs and NoSQL "databases" are crap solutions because they usually don't understand the problem. Like, I really like the look of Redis for instance, I do rather want to use it, but unfortunately it's "simple, elegant, and wrong".

# ? Aug 10, 2014 14:20

AWWNAW: Dec 30, 2008

havelock posted:

Stored procs (and statement mappers) don't compose.

You have to choose between fetching too much data (and then filtering/sorting/projecting in memory) or leaking database details through all your layers. An abstract criteria API handles some of this in a not-too-icky sort of way, but looks awfully primitive when compared to IQueryable. With Queryables at your layer boundaries, each component can filter/project/refine however it needs to and still (generally speaking) have everything collapse to a reasonable sql query. Plus you can easily test each layer in isolation using List<T>s or something.

The composition/abstraction benefits far outweigh the costs of the very slightly leaky abstraction (i.e., small amount of thinking required to not generate horribly queries).

SQL functions do compose with EF - you can query against them just like tables

also using linqkit u can write reusable predicates on the C# side

for the love of god disable lazy loading though esp if you work with bitch idiots

# ? Aug 10, 2014 15:49

z0rlandi viSSer: Nov 5, 2013

Stringent posted:

i wish Swift was usable as a general purpose language...

i wish everyone was dead

# ? Aug 10, 2014 15:51

TheresNoThyme: Nov 23, 2012

I used to hate ORM but then I realized that I just hated hibernate. Spring data is an example of a good ORM that does ORM's real job, which is minimizing the pain for that 90% of db queries that are brainless CRUD operations and, in a data service especially, should be created as simply and quickly as possible. This while still giving you a prescribed path to handle the 10% ugliness in a way that makes sense for your project (be that named queries, SP's, or even ORM if it's not too bad)

# ? Aug 10, 2014 16:08

FamDav: Mar 29, 2008

here's some dumb poo poo from hackreactor

# ? Aug 10, 2014 16:49

Shaggar: Apr 26, 2006

havelock posted:

Stored procs (and statement mappers) don't compose.

You have to choose between fetching too much data (and then filtering/sorting/projecting in memory) or leaking database details through all your layers. An abstract criteria API handles some of this in a not-too-icky sort of way, but looks awfully primitive when compared to IQueryable. With Queryables at your layer boundaries, each component can filter/project/refine however it needs to and still (generally speaking) have everything collapse to a reasonable sql query. Plus you can easily test each layer in isolation using List<T>s or something.

The composition/abstraction benefits far outweigh the costs of the very slightly leaky abstraction (i.e., small amount of thinking required to not generate horribly queries).

this is a myth perpetrated by bad developers. if your design is so loving bad that you are constantly rewriting your queries to the point that linq-to-sql is worthwhile, you need to fix your design, not double down on bad sql. stored procs are a far, far, far better abstraction than linq-to-sql which is in fact 0 abstraction. you are literally tying your db and app design as tightly as possible if you are writing queries within your code like that. stored procs (or views) are the only way to probably abstract your data from your application.

tl;dr: if your design isn't horrible development time difference between procs and sql-in-code is non-existent and then all you have left is stored proc's benefits of security and abstraction.

# ? Aug 10, 2014 17:33

TheresNoThyme: Nov 23, 2012

Shaggar posted:

tl;dr: if your design isn't horrible development time difference between procs and sql-in-code is non-existent and then all you have left is stored proc's benefits of security and abstraction.

Not every application benefits from having their database abstracted away into an architect's wet dream and requiring a DBA, who is often a separate resource, to be a blocker on every data access change and keeping his own silo of tribal knowledge safe from the app developers (see mr. dog's post about how the pure division of responsibilities never actually happens).

Like the fact that you can actually write "all you have left are all of abstraction's benefits" shows that you don't even think about the costs of that abstraction, which are quite real.

# ? Aug 10, 2014 18:16

suffix: Jul 27, 2013; Wheeee!

smart, well-bred people:
*writes a lightweight service backed by a database, using a sensible language, exposing an interface to applications and other services through one or more protocols like soap or thrift*

uneducated oafs:
*does the same thing, except the service is written in SQL, and also the exposed interface is SQL, and the service lives in the database and is probably not even under version control*

# ? Aug 10, 2014 18:23

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

if your application doesn't need (and will never need) an actual DBA and all the lark that comes with them, then your db interaction is almost certainly not gonna be limited by object-relational impedence mismatch so who the hell cares what strategy you use

# ? Aug 10, 2014 18:25

TheresNoThyme: Nov 23, 2012

coffeetable posted:

if your application doesn't need (and will never need) an actual DBA and all the lark that comes with them, then your db interaction is almost certainly not gonna be limited by object-relational impedence mismatch so who the hell cares what strategy you use

Eh I think you're under-estimating people's ability to abuse database mappings, and this can lead to giant timesinks even on "simple" applications. Strategy here is worth considering even if it's just to determine what will make your code easier to maintain and enhance moving forward.

# ? Aug 10, 2014 18:48

jony neuemonic: Nov 13, 2009

suffix posted:

uneducated oafs:
*does the same thing, except the service is written in SQL, and also the exposed interface is SQL, and the service lives in the database and is probably not even under version control*

we do this one.

[ASK] me about having "just suffix it with _old" as a version control strategy.

# ? Aug 10, 2014 18:50

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

fidel sarcastro posted:

we do this one.

[ASK] me about having "just suffix it with _old" as a version control strategy.

better than "_new", at least.

# ? Aug 10, 2014 18:56

Symbolic Butt: Mar 22, 2009; (_!_); Buglord

how do you sleep at night

# ? Aug 10, 2014 18:57

Notorious b.s.d.: Jan 25, 2003; by Reene

Shaggar posted:

you are literally tying your db and app design as tightly as possible if you are writing queries within your code like that. stored procs (or views) are the only way to probably abstract your data from your application.

abstracting my data from my application is not always a design goal.

it's true that data often outlives applications, and it's true that a database is often used by more than one application. statement mappers and SPs and carefully curated SQL become important when you know in advance that one of these things will be true.

sometimes i just want structured, persistent, transactional storage and i don't give too many fucks about the details. that is when i want an orm.

# ? Aug 10, 2014 19:44

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

orms are definitely better than inline sql

# ? Aug 10, 2014 19:45

Sapozhnik: Jan 2, 2005; Nap Ghost

I mean put it this way, the personal project that I wrote this janky mapper for has grown substantially (in complexity if not in meaningful userbase size) and I do wonder from time to time if I made the correct decision implementing it in this manner. It's not exactly a slam-dunk or everybody would be doing it, but on balance I feel like the alternatives are worse in one way or another.

# ? Aug 11, 2014 00:40

dragon enthusiast: Jan 1, 2010

yospos help me understand the difference between multiple dispatch and overloading

# ? Aug 11, 2014 02:17

Shaggar: Apr 26, 2006

TheresNoThyme posted:

Not every application benefits from having their database abstracted away into an architect's wet dream and requiring a DBA, who is often a separate resource, to be a blocker on every data access change and keeping his own silo of tribal knowledge safe from the app developers (see mr. dog's post about how the pure division of responsibilities never actually happens).

Like the fact that you can actually write "all you have left are all of abstraction's benefits" shows that you don't even think about the costs of that abstraction, which are quite real.

the quality of sql you write in your code isn't any different from what you'd write in the proc. there is no cost to the abstraction.

# ? Aug 11, 2014 02:20

Shaggar: Apr 26, 2006

Notorious b.s.d. posted:

abstracting my data from my application is not always a design goal.

it's true that data often outlives applications, and it's true that a database is often used by more than one application. statement mappers and SPs and carefully curated SQL become important when you know in advance that one of these things will be true.

sometimes i just want structured, persistent, transactional storage and i don't give too many fucks about the details. that is when i want an orm.

if your data isn't going to outlive your application you aren't doing real work

# ? Aug 11, 2014 02:21

Bloody: Mar 3, 2013

im doing real work and dont even use dtabases :confused:

# ? Aug 11, 2014 02:23

Phobeste: Apr 9, 2006; never, like, count out Touchdown Tom, man

dragon enthusiast posted:

yospos help me understand the difference between multiple dispatch and overloading

overloading is defined at compile time. multiple dispatch is runtime based on the type of the object at hand i think

# ? Aug 11, 2014 02:26

dragon enthusiast: Jan 1, 2010

Phobeste posted:

overloading is defined at compile time. multiple dispatch is runtime based on the type of the object at hand i think

wouldn't that just be the same as polymorphism though

or does md also extend to primitives or something like that

# ? Aug 11, 2014 02:39

Notorious b.s.d.: Jan 25, 2003; by Reene

Shaggar posted:

if your data isn't going to outlive your application you aren't doing real work

you're gonna have to explain this

you can't just let a turd like that float

# ? Aug 11, 2014 02:48

FamDav: Mar 29, 2008

dragon enthusiast posted:

wouldn't that just be the same as polymorphism though

or does md also extend to primitives or something like that

polymorphism is an umbrella that captures

single dispatch
multiple dispatch
ad hoc polymorphism
function overloading
operator overloading
parametric polymorphism
etc.

which are all variations on the idea that you can create a shape in which multiple implementations fit.

# ? Aug 11, 2014 03:09

fritz: Jul 26, 2003

Shaggar posted:

if your data isn't going to outlive your application you aren't doing real work

my data comes in at 50hz and sometimes gets to live in a little ring buffer

# ? Aug 11, 2014 04:00

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

fritz posted:

my data comes in at 50hz and sometimes gets to live in a little ring buffer

same but 367 hz

# ? Aug 11, 2014 04:02

tef: May 30, 2004; -> some l-system crap ->

Java code:

import java.net.*                                          ;
import java.io.*                                           ;
import java.util.*                                         ;
public class Server                                        { 
    public static void main( String[] args)                {
        try                                                {
            ServerSocket sock = new ServerSocket(4712,100) ;
            while(true) new Handler(sock.accept()).start() ;}
        catch(IOException e)                               {
            System.err.println(e)                          ;};}} 
 
class Handler extends Thread                               {
    public void run()                                      {
        Random random=new Random()                         ;
        try                                                {
            //yada yada yada
        catch(Exception e)                                 {
            System.err.println(e)                          ;};}}

# ? Aug 11, 2014 13:10

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 13:26

Shaggar: Apr 26, 2006

lol

# ? Aug 11, 2014 13:18

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »