Shaggar posted:

I liked knockout but the SPA routing poo poo is always super unmanageable. luckily steve sanderson has moved on from knockout and is working on fixing browsers forever with blazor

https://www.youtube.com/watch?v=MiLAE6HMr10&t=1860s

best thing ever is at 33:08

Shinku ABOOKEN posted:

hey all can anyone tell me what i'm doing wrong here in this pom.xml? i want to try out jetty but maven tries to download a non-existent jar (https://repo.maven.apache.org/maven2/org/eclipse/jetty/jetty-project/9.4.7.RC0/jetty-project-9.4.7.RC0.jar)

XML code:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 [url]http://maven.apache.org/xsd/maven-4.0.0.xsd[/url]">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>project</artifactId>
    <version>1.0-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-project</artifactId>
            <version>9.4.7.RC0</version>
        </dependency>
    </dependencies>


</project>

e: i'm using intellij's built in maven 3

MALE SHOEGAZE posted:

slick is bullshit. gently caress slick.

here's the basic sql query I'm trying to write in slick:

code:

select invoice.id, sum(item.price) 
	from public."INVOICE" as invoice 
	join public."INVOICE_ITEM" as item on invoice.id = item.invoice_id 
	group by invoice.id;

here it is in slick!

code:

    val joined = invoiceTable join invoiceItemTable on (_.id === _.invoice_id)
    val grouped =
      joined.groupBy(_._1).map { case (invoice, grouped) => (invoice, grouped.map(_._2.price).sum) }

    db.run(grouped.result)
      .map(_.map { case (invoice, price) => invoice.copy(price = price.getOrElse(0)) })

i'm not going to post the generated code because it sucks but also it doesn't even properly parameterize poo poo so there's an attack vector there. it may be that it doesn't parameterized UUIDs because in theory a parsed UUID is injection safe but idk. i jsut dont know.

oh and it has an escape hatch in the form of plain sql queries. but guess what? it doesn't support interpolation of traversable types so you cant even do IN properly.

I'm switching to scalalike and I should have done so last week when gonadic io mentioned it.

MALE SHOEGAZE posted:

slick is bullshit. gently caress slick.

here's the basic sql query I'm trying to write in slick:

code:

select invoice.id, sum(item.price) 
	from public."INVOICE" as invoice 
	join public."INVOICE_ITEM" as item on invoice.id = item.invoice_id 
	group by invoice.id;

here it is in slick!

code:

    val joined = invoiceTable join invoiceItemTable on (_.id === _.invoice_id)
    val grouped =
      joined.groupBy(_._1).map { case (invoice, grouped) => (invoice, grouped.map(_._2.price).sum) }

    db.run(grouped.result)
      .map(_.map { case (invoice, price) => invoice.copy(price = price.getOrElse(0)) })

i'm not going to post the generated code because it sucks but also it doesn't even properly parameterize poo poo so there's an attack vector there. it may be that it doesn't parameterized UUIDs because in theory a parsed UUID is injection safe but idk. i jsut dont know.

oh and it has an escape hatch in the form of plain sql queries. but guess what? it doesn't support interpolation of traversable types so you cant even do IN properly.

I'm switching to scalalike and I should have done so last week when gonadic io mentioned it.

JewKiller 3000 posted:

you already have the sql query so just use the sql query

i have yet to see a sql translation layer that 1. actually has all the features you need, and 2. is any better than sql in any way whatsoever. like yeah ok "object relational impedance mismatch! embedded strings of code written in another language! blah blah blah" who cares just use the sql

Shaggar posted:

you wouldn't add jetty as a dependency unless you're doing development on a jetty extension or something. Also that doesn't look like a valid jetty version.

you want to use the jetty plugin to have maven run your project on jetty during development and testing. I also added the servlet-api in here if that's what you're using jetty for. if not you can remove that dependency.

XML code:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 [url]http://maven.apache.org/xsd/maven-4.0.0.xsd[/url]">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>project</artifactId>
    <version>1.0-SNAPSHOT</version>

    <dependencies>
        <dependency>
             <groupId>javax.servlet</groupId>
			<artifactId>javax.servlet-api</artifactId>
			<version>3.1</version>
			<scope>provided</scope>
        </dependency>
    </dependencies>
	<plugins>
		
		<plugin>
			<groupId>org.eclipse.jetty</groupId>
			<artifactId>jetty-maven-plugin</artifactId>
			<version>9.4.6.v20170531</version>
		</plugin>
	</plugins>


</project>

after adding the plugin you'll be able to run the goals it provides. You can get more info on that from the plugin website here but if you just run your project with jetty:run it will first download all the reqs for the plugin including the jetty runtime and then start jetty with your project's output as the home dir.

Shaggar posted:

use mybatis and stop wasting your time with stupid crap.

MALE SHOEGAZE posted:

i agree in principal but i need the following features:

1) proper query parameterization
2) something that handles the quirks of jdbc for me
3) something that handles connections
4) something that presents an asynchronous Future based API.

also gently caress scalalike doesn't support futures so there goes that.

gonadic io posted:

Future.apply

MALE SHOEGAZE posted:

I could probably sneak that by my lead honestly.

gonadic io posted:

honestly i don't get the difference between putting it into future threads yourself and the "proper" async future solution

gonadic io posted:

but my question is more what's the difference between starting the computation in a thread vs the "proper" async way with library support?

quote:

so twitter's Future.apply is like scala's Future.successful? that's p stupid imo.

Shinku ABOOKEN posted:

thank you

my goal is to have a server that i can drop somewhere behind an nginx. will this accomplish my goal? will the maven-plugin be included in the final artifact? (i am not familiar with the specifics of java servers)

redleader posted:

i thought nginx is open source and therefore garbage?

cinci zoo sniper posted:

i have gotten to point of doing actual work with mongo and my desire to kill has never been so high, drat

Shaggar posted:

MALE SHOEGAZE posted:

it's so bad

cinci zoo sniper posted:

how do i traverse a nested substructure with bunch of nested substructures to retrieve all Butt on any of varying levels?

gonadic io posted:

Sounds like you need a hylofunctor

redleader posted:

i thought nginx is open source and therefore garbage?

cinci zoo sniper posted:

how do i traverse a nested substructure with bunch of nested substructures to retrieve all Butt on any of varying levels?

necrotic posted:

Shoot the mongo database into a volcano and use a real database.

necrotic posted:

Also send whoever chose mongo to the volcano.

necrotic posted:

Shoot the mongo database into a volcano and use a real database.

necrotic posted:

Also send whoever chose mongo to the volcano.

necrotic posted:

Also send whoever chose mongo to the volcano.

cinci zoo sniper posted:

ok, now im at pc and can elaborate

say, mongo entry has as field with a json blob, in which I have bunch of strings each called Butt

repsonse.x.y.z.Butt
repsonse.x.y.z.hello.Butt
repsonse.x.y.z.hello.world.1.Butt
repsonse.x.y.z.hello.world.2.Butt

i can guarantee that all Butts are inside z, but i can not claim that each record has the exactly same position (sublevel depth) and number of Butts within z

is there an elegant-ish solution for this in a javascript select query for mongodb

JewKiller 3000 posted:

sup nerds i just wrote a query that has 3 ctes and uses an inner join, a left join, a right join, and two full joins

JewKiller 3000 posted:

just imagine, if your documents were in xml, the solution would be the xpath "//Butt" from the z node

Shaggar posted:

ctes are good