scala-dbc

[Mikael Ståldal]

I Scala-distributionen så finns det en fil scala-dbc.jar som innehåller paketet scala.dbc.

Vad är detta? Var hittar man dokumentation över detta?

--
Mikael Ståldal
Senior Software Engineer
Appear Networks
Tel: +46 8 545 91 370

[John Nilsson]

Ett deprecated databas API?

http://scala.sygneca.com/libs/dbc
http://www.scala-lang.org/api/2.7.0/scala/dbc$package.html

Antar att du får motsvarande funktionallitet via något av
http://squeryl.org/
http://www.sts.tu-harburg.de/people/mi.garcia/ScalaQL/
http://scalaquery.org/

Hittade även en trevlig lista på
http://stackoverflow.com/questions/1362748/wanted-good-examples-of-scala-database-persistence

Av de ramverk jag känner till så tycker jag ScalaQL verkar vara
"rätt"-lösning. Men jag har ingen aning om hur mycket utveckling det
sker på den fronten.

Mvh,
John

2011/3/21 Mikael Ståldal <mikael....@appearnetworks.com>:

> --
> Det här meddelandet skickas till dig eftersom du prenumererar på gruppen
> scala-sverige i Google Groups.
> Om du vill göra ett inlägg i den här gruppen skickar du e-post till
> scala-...@googlegroups.com.
> Om du vill sluta prenumerera på den här gruppen skickar du e-post till
> scala-sverig...@googlegroups.com.
> För fler alternativ, besök gruppen på
> http://groups.google.com/group/scala-sverige?hl=sv.
>

[√iktor Klang]

Det beror iofs på, jag rekommenderar att man undviker ORM-approachen som pesten.

2011/3/21 John Nilsson <jo...@milsson.nu>

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

[John Nilsson]

Om man kan... ;-)

Mvh,
John

2011/3/21 √iktor Klang <viktor...@gmail.com>:

[Henrik Johansson]

Jag har fastnat för ScalaQuery, även om det inte är precis som jag vill ha det. Det är mycket ORM-fluff och DDL-generering i det, men det riktigt smaskiga är att jobba direkt med tupler mot databasen:

val kundId = 3

val kunder:List[(String,String)] = db withSession {

   query[Int,(String,String)]("""SELECT fornamn, efternamn FROM kunder WHERE id = ?""") (kundId) list

}

/Henrik

2011/3/21 John Nilsson <jo...@milsson.nu>

--
t.  +46 707 - 45 53 90

[Olle Kullberg]

Vi kör Querolous vilket är mycket lättviktigt. Tyvärr bygger Querolous på Scala 2.7, så i ren desperation gjorde jag en usel fork för Scala 2.8: https://github.com/ollekullberg/querulous-light
-------------------

This is a fork of Querulous-generic (Querulous-generic is in turn a fork of the Twitter version). This fork will:

• Work on Scala 2.8
• Work on all RDBMs (Well, I've only tried H2, so I do not really know)
• Not have any dependencies to Twitters StandardProject module.

The more advanced features (timeout and so on) probably don't work, since I had to smash some code to get here.

-------------------

/0113

2011/3/21 Henrik Johansson <hen...@gmail.com>

[Mats Henricson]

Jobbigt läge att behöva välja, känns det som. Ska försöka göra lite mer research.

Mats

2011/3/22 Olle Kullberg <olle.k...@gmail.com>

[Mats Henricson]

Tog en titt på syntaxen för ScalaQuery, och tyckte den avskräckte en del.

Men det är nog bara jag.

Mats

2011/3/21 Henrik Johansson <hen...@gmail.com>

[Henrik Johansson]

Tittar man paa hur ScalaQuerys author vill att man använder det haaller jag med dig fullständigt. Det är just StaticQuery som är godbiten (se mitt exempel.). 

- Men det hör till historien att jag är allergisk mot att använda dassiga query-spraak (HQL/JPAQL mfl.) och DSLer (ScalaQuery, Squeryl).

I mitt exempel använder jag hederlig SQL och kan själv mappa tupler till Case Classes.

/Henrik

2011/3/22 Mats Henricson <mats.he...@gmail.com>

[anpeo]

Runt mig tala det mycket om ORM och hur bra det är dock i en C# värld, skulle vara snällt om du kunde berätta varför du gärna undviker det

är det en Scala sak eller något rent generelllt. ?

/A

[Joakim Ohlrogge]

+1

[Joakim Ohlrogge]

Snabbt på gående fot från mobilen.

Mina två senaste kunder har haft problem med just orm. Detta är i java och i det ena talet i kombination med Scala men problemen fanns redan med bara java.

En orm löser som jag ser det två saker.

1. Databasoberoende (nåja. Nästan )
2. Sql är svårt
(off by One: man vill alltid knöka in data i en domänmodell som får se ut hur den vill så länge man slipper skapa objekten själv)

1: problemet försvinner inte. Det ändrar form. Och handen på hjärtat. Hur ofta byter man egentligen?
2: orm är också svårt. Det är minst lika svårt att bli tillräckligt bra på hibernate som att bli tillräckligt bra på sql . Lär man sig sql sådan man hantera alla relarionsdatabaser lär man sig hibernate kan man... Hibernate  och man behöver sannolikt kunna sql ändå.
Just nu jobbar jag med att snabba upp rapporter som mina föregångare lämnat efter sig. De befintliga rapporterna tar samtliga mellan 45 minuter och 12 timmar. Oftast runt 5 timmar. Våra "optimerade " rapporter mellan 45s och 10min.
Och då är jag inte ens bra på sql.

Dock har det inte alltid varit smärtfritt att göra optimeringen. Om man arbetat i 5 år med enl mönstret: sköt upp en tångruska ur orm och rensa den med java så upptäcker man då man ska skriva sql mot dbn  att modellen lämpar sig bättre att lagra objekt i än att ställa frågor mot.
Vi har fått ta till diverse bricka tricks som joins mot temporära tabeller innehållande unionen av 5 andra tabeller.

Slutsats: jag vet inte om en orm löser något problem som är värt att lösa men jag skulle kunna prata i timmar om vilka de skapar och hur man fastnar i den sämsta av två världar

Ps blir man riktigt vass på orm så ser det ut som om man kan få ägna sig åt att lösa riktiga problem som att skriva ett språk för jvmen som "vanliga" utvecklare förstår:ceylon ds

--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.

Om du vill visa den här diskussionen på webben besöker du https://groups.google.com/d/msg/scala-sverige/-/cYMp9Rc5HQsJ.

[Mikael Ståldal]

2011/12/1 Joakim Ohlrogge <joakim....@agical.com>

En orm löser som jag ser det två saker.

1. Databasoberoende (nåja. Nästan ) 

1: problemet försvinner inte. Det ändrar form. Och handen på hjärtat. Hur ofta byter man egentligen?

Om man bygger en produkt som olika kunder använder med olika relationsdatabaser så är databasoberoende väldigt viktigt.

--

Mikael Ståldal

Senior Software Engineer Appear Kista Science Tower 164 51 Kista Sweden Phone: + 46 (0)8 545 91 572 Mobile: + 46 (0)70 1479581 Email: mikael.staldal@appearnetworks.com Visit us at: www.appearnetworks.com

[Joakim Ohlrogge]

Då vet man vilket problem man försöker lösa med en ORM. Är en ORM det lättaste sättet att lösa det problemet och är man medveten om vilka andra problem man skaffar sig?
-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
Twitter: @johlrogge
E-mail: joakim....@agical.se

2011/12/1 Mikael Ståldal <mikael....@appearnetworks.com>

--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.

[√iktor Ҡlang]

CQRS + ES

2011/12/1 Joakim Ohlrogge <joakim....@agical.com>

--
Viktor Klang

Akka Tech Lead

Typesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

[Olle Kullberg]

Något som jag har funderat på en tid är att faktiskt börja använda ORM (trots mitt initiala motstånd). Anledningen är CQRS. En mycket enkel variant av CQRS skulle vara att använda ORM för triviala operationer (typ CRUD) och JDBC för icke-triviala sql, där man i det generella fallet har två databaser optimerade för transaktioner resp analys.

Men, här funderar jag på om man inte lika gärna kan köra MongoDB istället för ORM för triviala operationer, och JDBC för icke-trivial sql?

Vad tror ni?

2011/12/1 Joakim Ohlrogge <joakim....@agical.com>

[√iktor Ҡlang]

2011/12/1 Olle Kullberg <olle.k...@gmail.com>

Något som jag har funderat på en tid är att faktiskt börja använda ORM (trots mitt initiala motstånd). Anledningen är CQRS. En mycket enkel variant av CQRS skulle vara att använda ORM för triviala operationer (typ CRUD) och JDBC för icke-triviala sql, där man i det generella fallet har två databaser optimerade för transaktioner resp analys.

Men, här funderar jag på om man inte lika gärna kan köra MongoDB istället för ORM för triviala operationer, och JDBC för icke-trivial sql?

Absolut, att hålla på med ORM när man lika gärna kan köra Salat + Mongo blir ju bara konstigt.
Däremot rekommenderar jag definitivt ES då man oftare ändrar sin aggregatmodell än man ändrar innehållet i sina affärshändelser.

Cheers,
√
 

--

[Joakim Ohlrogge]

mongo + JDBC funkar ju om man inte vill köra de triviala operationerna på samma data som de avancerade operationerna (?)

Att blanda JDBC och orm är precis vad vi gör här. Vi försöker strypa ut ORM:en helt enkelt. Dock får man vara lite försiktig. Om man bara läser med JDBC så går det säkert bra (om man vet att cachear är flushade innan man frågar). Skriver man vid sidan av med JDBC så kan man behöva använda lite annorlunda tricks för att cachaer och dylikt ska invalideras.

Personligen är det inte något jag skulle ge mig in i frivilligt men jag är nog lite av ett bränt barn...

-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
Twitter: @johlrogge
E-mail: joakim....@agical.se

2011/12/1 Olle Kullberg <olle.k...@gmail.com>

[John Nilsson]

Oj gammal tråd ! :)

Min erfarenhet är att ORM:er dels abstraherar bort så mycket av den rationella modellen och den underliggande databasen att du tappar det det mesta den kan erbjuda. Varför backa din modell rationellt om du ändå inte drar nytta av det? Dels så tvingar de in objekt-modellen i ett datacentrikt perspektiv vilket gör att du samtidigt tappar möjligheten och nyttan med en objektorienterad modell.

Resultatet ORM blir därför bara mappning, vilket bara är kostnad.

Eventsourcing och CQRS verkar erbjuda ett alternativ som jag håller på att utvärdera för tillfället. Du får fråga igen om ett år så skall vi se om jag reviderat min ståndpunkt ;)

MVH,
John

[Joakim Ohlrogge]

Åh vad bra formulerat!

-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
Twitter: @johlrogge
E-mail: joakim....@agical.se

2011/12/1 John Nilsson <jo...@milsson.nu>

[√iktor Ҡlang]

2011/12/1 Joakim Ohlrogge <joakim....@agical.com>

Åh vad bra formulerat!

Johnny är rätt badass.
 

[Olle Kullberg]

För CRUD-operationer funkar allt: ORM, Relationsmodell, Dokumentmodell...

@Joakim Om man för över data kontinuerligt från en dokumentdatabas till en analysdatabas (ES) så får man nästan samma data. Man måste nog räkna med att analysdatabasen ligger några millisekunder efter (vilket kan ge fel). 

/olle

2011/12/1 √iktor Ҡlang <viktor...@gmail.com>

[Peter Lundberg]

+1 för abstraktionsproblemet som John beskrev!

Jag har även en komplexitetsvy på det: Även om allt fungerar för CRUD, tycker jag att man skall man beakta hur mycket komplexitet man drar in i sin lösning och inte falla för “golden hammer” anti-pattern.

Och då menar jag inte bara den komplexitet man skriver själv, orm med annoteringar ser förföriskt enkelt ut, utan mest hur många lager teknologi och rader kod och beroenden som man plockar in för att lösa problemet. Denna dolda komplexitet är något jag tycker många inte ser eller tar hänsyn till – tar man in teknologin skall man underhålla den över tiden och den skall funka. När den inte fungerar måste de som vidareutvecklaresystemet kunna felsöka och förstå den, även om några år. Jfr en klassisk orm strack (spring + hibernate + cache + jdbc driver + RDBMS + filsystem) med enkla filer (java.io + filsystem) med någon nosql (driver + enkla operationer + filsystem). Storleken på ens lib katalog i drift är ett grovt men intressant mått.

Mvh
Peter

On 11-12-01 10:15 , "Olle Kullberg" <olle.k...@gmail.com> wrote:

För CRUD-operationer funkar allt: ORM, Relationsmodell, Dokumentmodell...

@Joakim Om man för över data kontinuerligt från en dokumentdatabas till en analysdatabas (ES) så får man nästan samma data. Man måste nog räkna med att analysdatabasen ligger några millisekunder efter (vilket kan ge fel). 

/olle

2011/12/1 √iktor Ҡlang <viktor...@gmail.com>

2011/12/1 Joakim Ohlrogge <joakim....@agical.com>

Åh vad bra formulerat!

Johnny är rätt badass.
 

-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004 <tel:%2B46-708-754004>
Blog: johlrogge.wordpress.com <http://johlrogge.wordpress.com>

Twitter: @johlrogge
E-mail: joakim....@agical.se


2011/12/1 John Nilsson <jo...@milsson.nu>

[Henrik Johansson]

+1

ORMerna lovade databasoberoende och att man skulle slippa skriva SQL
och slippa mappa sina objektstrukturer.

* Numera har vi insett att de inte ger databasoberoende (queries som
fungerar olika). Låtsas du att stöder alla databaser måste du också
testa det. Då börjar det kosta.
* SQL är inte svårt, det är däremot kraftfullt och tydligt. Ofta blir
det merjobb för att få sin ORM att ställa rätt SQL-fråga. Resultatet
blir att jag måste hantera både SQL och en ORM.
* Objektstrukturer: Det är ju trots allt bara data och operationer.
Måste det vara ett objekt? Hämta datan, visa den, manipulera den nära
databasen istället. Ofta har vi rader av data i databasen, vi mappar
dem till objekt, och visar rader av data på en webbsida. - Vad tillför
objektmappningen till lösningen?
* Om du skall testa dina queries inuti din IDE, vad är enklast att
sätta upp och testa: Mappade hibernate-objekt eller ett JDBC-anrop?

Henrik Johansson

On 1 Dec, 10:37, Peter Lundberg <peter.lundberg...@gmail.com> wrote:
> +1 för abstraktionsproblemet som John beskrev!
>
> Jag har även en komplexitetsvy på det: Även om allt fungerar för CRUD,
> tycker jag att man skall man beakta hur mycket komplexitet man drar in i sin
> lösning och inte falla för “golden hammer” anti-pattern.
>
> Och då menar jag inte bara den komplexitet man skriver själv, orm med
> annoteringar ser förföriskt enkelt ut, utan mest hur många lager teknologi
> och rader kod och beroenden som man plockar in för att lösa problemet. Denna
> dolda komplexitet är något jag tycker många inte ser eller tar hänsyn till –
> tar man in teknologin skall man underhålla den över tiden och den skall
> funka. När den inte fungerar måste de som vidareutvecklaresystemet kunna
> felsöka och förstå den, även om några år. Jfr en klassisk orm strack (spring
> + hibernate + cache + jdbc driver + RDBMS + filsystem) med enkla filer
> (java.io + filsystem) med någon nosql (driver + enkla operationer +
> filsystem). Storleken på ens lib katalog i drift är ett grovt men intressant
> mått.
>
> Mvh
> Peter
>

> On 11-12-01 10:15 , "Olle Kullberg" <olle.kullb...@gmail.com> wrote:
>
>
>
>
>
>
>
> > För CRUD-operationer funkar allt: ORM, Relationsmodell, Dokumentmodell...
>
> > @Joakim Om man för över data kontinuerligt från en dokumentdatabas till en
> > analysdatabas (ES) så får man nästan samma data. Man måste nog räkna med att
> > analysdatabasen ligger några millisekunder efter (vilket kan ge fel).
>
> > /olle
>

> > 2011/12/1 √iktor Ҡlang <viktor.kl...@gmail.com>
>
> >> 2011/12/1 Joakim Ohlrogge <joakim.ohlro...@agical.com>

> >>> Åh vad bra formulerat!
>
> >> Johnny är rätt badass.
> >>
>
> >>> -----------------------------------------------------
> >>> Joakim Ohlrogge
> >>> Agical AB
> >>> Västerlånggatan 79, 2 tr
> >>> 111 29 Stockholm, SWEDEN
>
> >>> Mobile: +46-708-754004 <tel:%2B46-708-754004>
> >>> Blog: johlrogge.wordpress.com <http://johlrogge.wordpress.com>
> >>> Twitter: @johlrogge

> >>> E-mail: joakim.ohlro...@agical.se
>
> >>> 2011/12/1 John Nilsson <j...@milsson.nu>

>
> >>>> Oj gammal tråd ! :)
>
> >>>> Min erfarenhet är att ORM:er dels abstraherar bort så mycket av den
> >>>> rationella modellen och den underliggande databasen att du tappar det det
> >>>> mesta den kan erbjuda. Varför backa din modell rationellt om du ändå inte
> >>>> drar nytta av det? Dels så tvingar de in objekt-modellen i ett datacentrikt
> >>>> perspektiv vilket gör att du samtidigt tappar möjligheten och nyttan med en
> >>>> objektorienterad modell.
>
> >>>> Resultatet ORM blir därför bara mappning, vilket bara är kostnad.
>
> >>>> Eventsourcing och CQRS verkar erbjuda ett alternativ som jag håller på att
> >>>> utvärdera för tillfället. Du får fråga igen om ett år så skall vi se om jag
> >>>> reviderat min ståndpunkt ;)
>
> >>>> MVH,
> >>>> John
>

[Joakim Ohlrogge]

Den mest eleganta "mappningen" jag sett hittills är en lösning där en klass (tex User) mostvarades av ett paket i oracle (tex PK_User). En operation på objektet motsvarades av en stored proceduere (tex PK_ADD). Innan jag arbetade med en lösningen hatade jag stored procedures... efter det kände jag att det var den modellen jag sett som kompromissade minst åt något håll (OO <-> RDBMS). Storrarna var så att säga det integrationslager som brukar göras i XML i ORM-lösningar

Men som sagt, är det objekt man vill lagra så erbjuder ju nutidens teknik lite andra lösningar än RDBMS.

Intressant tråd!

-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004

Blog: johlrogge.wordpress.com
Twitter: @johlrogge
E-mail: joakim....@agical.se

2011/12/1 Henrik Johansson <hen...@gmail.com>

[John Nilsson]

Ja Oracle stödjer faktiskt förvånansvärt mycket, det är nästan som att faktiskt implementerat industrial D!*
Synd  bara att PL/SQL är ett så kasst språk.

En annan elegant "mappning" är den som F# kommer med i nästa release. Type generators kallar de det. Intellisense direkt mot databasen med integrerad kodgenerering på det för att typa resultatet.

Mvh,
John

* Se Third Manifesto

[√iktor Ҡlang]

2011/12/1 John Nilsson <jo...@milsson.nu>

Ja Oracle stödjer faktiskt förvånansvärt mycket, det är nästan som att faktiskt implementerat industrial D!*

Hahaha, jag kommer ihåg alla roliga ögonblick du haft roligt med Oracle.
 

Synd  bara att PL/SQL är ett så kasst språk.

Språket är inte lika kasst som runtimen... ;)

 

En annan elegant "mappning" är den som F# kommer med i nästa release. Type generators kallar de det. Intellisense direkt mot databasen med integrerad kodgenerering på det för att typa resultatet.

Type Providers heter det väl?

Cheers,
√
 

--

[Joakim Ohlrogge]

Jo, och det är nästan minst lika förvånande hur mycket det är som Oracle /inte/ stöder :)

-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
Twitter: @johlrogge
E-mail: joakim....@agical.se

2011/12/1 John Nilsson <jo...@milsson.nu>

[John Nilsson]

Ah det gör det nog, my bad.

Jodå Oracle och jag har haft en och annan dunst ... ;)
Som det ser ut kommer jag nog ha minst lika roligt med MSSQL. Nåja får se om inte RavenDB kan bidra med lite avslappning.

Mvh,
John

[√iktor Ҡlang]

2011/12/1 John Nilsson <jo...@milsson.nu>

Ah det gör det nog, my bad.

Jodå Oracle och jag har haft en och annan dunst ... ;)
Som det ser ut kommer jag nog ha minst lika roligt med MSSQL. Nåja får se om inte RavenDB kan bidra med lite avslappning.

Det jag tycker är trist med SQL är att frågor inte är komponeringsvänliga, vilket leder till copy-paste-style programmering, vilket är svårt att underhålla.

 

[John Nilsson]

Higher order SQL FTW! :-)

Det är väl dags för en ny standard snart. Får se om inte Greg uppfinner något djävulsk smart i sin bok. ;-)

Mvh,
John

[Mikael Ståldal]

2011/12/1 Olle Kullberg <olle.k...@gmail.com>

Men, här funderar jag på om man inte lika gärna kan köra MongoDB istället för ORM för triviala operationer, och JDBC för icke-trivial sql?

Hur ska det gå till? MongoDB stödjer väl varken JDBC eller SQL?
 

[Mikael Ståldal]

2011/12/1 Henrik Johansson <hen...@gmail.com>

* SQL är inte svårt, det är däremot kraftfullt och tydligt. Ofta blir
det merjobb för att få sin ORM att ställa rätt SQL-fråga. Resultatet
blir att jag måste hantera både SQL och en ORM.

SQL är bra för att ställa icke-triviala frågor. Men om man har tabeller med många fält så blir det trist och "error-prone" att göra enkel CRUD med SQL.

[Henrik Johansson]

2011/12/2 Mikael Ståldal <mikael....@appearnetworks.com>

2011/12/1 Henrik Johansson <hen...@gmail.com>

* SQL är inte svårt, det är däremot kraftfullt och tydligt. Ofta blir
det merjobb för att få sin ORM att ställa rätt SQL-fråga. Resultatet
blir att jag måste hantera både SQL och en ORM.

SQL är bra för att ställa icke-triviala frågor. Men om man har tabeller med många fält så blir det trist och "error-prone" att göra enkel CRUD med SQL.

Jag håller med om att man måste hålla tungan rätt i mun när man mappar fälten, men det är en enkel uppgift och du betalar bara för den en gång. Det är enklare att mappa 100 fält manuellt än att dra på extra komplexitet, vikt och bytecode-generation. Lösningen måste ändå testas, så blir det fel märker du det på samma vis.

I mina utvecklingsprojekt brukar jag använda ett ORM-genererat schema för att testa att uppgraderingsscripten resulterar i samma shema som är "current". Det är något som jag kommer att sakna utan ORM.

Vänligen,

Henrik Johansson

[Mikael Ståldal]

2011/12/2 Henrik Johansson <hen...@gmail.com>

2011/12/2 Mikael Ståldal <mikael....@appearnetworks.com>

2011/12/1 Henrik Johansson <hen...@gmail.com>

* SQL är inte svårt, det är däremot kraftfullt och tydligt. Ofta blir
det merjobb för att få sin ORM att ställa rätt SQL-fråga. Resultatet
blir att jag måste hantera både SQL och en ORM.

SQL är bra för att ställa icke-triviala frågor. Men om man har tabeller med många fält så blir det trist och "error-prone" att göra enkel CRUD med SQL.

Jag håller med om att man måste hålla tungan rätt i mun när man mappar fälten, men det är en enkel uppgift och du betalar bara för den en gång.

Man betalar varje gång man ändrar i databasschemat.

Uppgiften är enkel, men repetitiv, tråkig och "error-prone". Alltså en uppgift som datorer är bättre på att göra än människor. För oss som gillar statiskt typade språk är det frustrerande att inte få någon hjälp av kompilatorn om man stavar något kolumnnamn fel.

Jag tycker inte det är en tillfredställande lösning att göra enkel CRUD manuellt med SQL. Jag skulle vilja ha någon form av mini-ORM som bara hjälper till med CRUD, men inte gör allt annat som t.ex. JPA och Hibernate gör.
 

[Henrik Johansson]

2011/12/2 Mikael Ståldal <mikael....@appearnetworks.com>

2011/12/2 Henrik Johansson <hen...@gmail.com>

2011/12/2 Mikael Ståldal <mikael....@appearnetworks.com>

2011/12/1 Henrik Johansson <hen...@gmail.com>

* SQL är inte svårt, det är däremot kraftfullt och tydligt. Ofta blir
det merjobb för att få sin ORM att ställa rätt SQL-fråga. Resultatet
blir att jag måste hantera både SQL och en ORM.

SQL är bra för att ställa icke-triviala frågor. Men om man har tabeller med många fält så blir det trist och "error-prone" att göra enkel CRUD med SQL.

Jag håller med om att man måste hålla tungan rätt i mun när man mappar fälten, men det är en enkel uppgift och du betalar bara för den en gång.

Jag tycker inte det är en tillfredställande lösning att göra enkel CRUD manuellt med SQL. Jag skulle vilja ha någon form av mini-ORM som bara hjälper till med CRUD, men inte gör allt annat som t.ex. JPA och Hibernate gör.

Jag håller med dig, det finns definitivt en sweet-spot för en mini-ORM som inte försöker ta över världen.

 

[√iktor Ҡlang]

Neej, inte CRUD, bara C!

2011/12/2 Henrik Johansson <hen...@gmail.com>

--

Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.

[Joakim Ohlrogge]

Rätta mig om jag har fel men brukar inte tex hibernate ha hbm-filer eller anotations där man talar om vilken kolumn som ska in i vilket fält? Så den mappningen är väl lika error prone i xml som i java/scala? 

Dock kan det ju vara kul om man slipper skriva rs.getLong och så som jag löst det några gånger är att man ser till att resultatets kolumner har namn som går att mappa direkt mot namn på fält i ett objekt. Tex genom att använd 'as <namn>'.

SQL:en är så att säga mappningsfilen. Skulle tabellerna redan ha kolumner med passande namn är det ju bara att göra select *

Det är ett väldigt litet problem som borde ha en väldigt liten lösning. Som du skriver, en liten mini-orm, fast jag tycker select syntaxen är tillräckligt kompakt som mappningsspråk...

-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004

Blog: johlrogge.wordpress.com
Twitter: @johlrogge
E-mail: joakim....@agical.se

2011/12/2 Henrik Johansson <hen...@gmail.com>

--

[Mikael Ståldal]

2011/12/2 Joakim Ohlrogge <joakim....@agical.com>

Rätta mig om jag har fel men brukar inte tex hibernate ha hbm-filer eller anotations där man talar om vilken kolumn som ska in i vilket fält?

Jo, men det är frivilligt, by default antas att fältet och kolumen har samma namn.
 

Det är ett väldigt litet problem som borde ha en väldigt liten lösning. Som du skriver, en liten mini-orm, fast jag tycker select syntaxen är tillräckligt kompakt som mappningsspråk...

Mappningen mellan fält i Scala och kolumn i DB ska vara helt automatisk, baserad på att de har samma namn.
 

[Joakim Ohlrogge]

Jo givet att allt har samma namn är det sista att optimera bort

select * from MyType

"select * from " + classOf[MyType].simpleName

typ

def readQuery[T](implicit m:Manifest[T]) = "select * from "+m.erasure.simpleName

eller något. Dvs, man kan utogenerera defaultfrågor och o default inte funkar kan man göra sin mappning som en egen select...

Jaja, känns som att vi börjar krympa ner det man verkligen vill ha till något ganska litet. Vore kul om den här diskussionen kunde mynna ut i något git-repo som implementerar denna lilla micro mapper...

/J

-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
Twitter: @johlrogge
E-mail: joakim....@agical.se

2011/12/2 Mikael Ståldal <mikael....@appearnetworks.com>

[√iktor Ҡlang]

foo.Bar och baz.Bar clash, så du måste göra name-mangling

[Joakim Ohlrogge]

Ja i de fall det finns en foo.Bar och en baz.Bar och båda måste läsas från samma databas. Och då kan man ju alltid skriva sin egen lilla SQL/vy/... för att ta hand om de fallen precis som man måste skriva sin egen annotering/hbm i hibernate för att ta hand om samma fall.

Dock kan jag inte påstå att skilja på User och User eller Company och Company är ett problem jag stött på jätte ofta. Det är väl antagandet som görs i hibernates default och ett ganska rimligt defaultantagande kan jag tycka så länge man kan hantera de situationer då default inte är bra nog. Och det kan man ju med helt vanlig bonn-SQL.

Detta gällde ju att inte behöva skriva någon mappning om namnen i databasen mostvarar namnen i koden.

Eller missuppfattade jag det?

-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
Twitter: @johlrogge
E-mail: joakim....@agical.se

2011/12/2 √iktor Ҡlang <viktor...@gmail.com>

[√iktor Ҡlang]

klassnamnet innefattar ju paketet. så fort man kortar så skär man hörn

[Joakim Ohlrogge]

Absolut, jag vidhåller att hörnen går att skära i de allra flesta fall och har man särskilda behov så kan man sköta sin mappning precis lika bra i sql som i HBM. Jag ville bara visa att man kan skapa en lika bra fråga utifrån en typ som hibernate kan skapa åt mig utan mappning. Jag är helt fine med att skriva sql:en.

Eller tycker du att jag kapat några andra hörn än vad tex hibernate gör för att åstadkomma samma sak?

/J
-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
Twitter: @johlrogge
E-mail: joakim....@agical.se

2011/12/2 √iktor Ҡlang <viktor...@gmail.com>

[√iktor Ҡlang]

Absolut, så länge inte äpplen och päron blandas, dvs fail early.

[Mikael Ståldal]

2011/12/2 Joakim Ohlrogge <joakim....@agical.com>

Jo givet att allt har samma namn är det sista att optimera bort

select * from MyType

"select * from " + classOf[MyType].simpleName

typ

def readQuery[T](implicit m:Manifest[T]) = "select * from "+m.erasure.simpleName

eller något. Dvs, man kan utogenerera defaultfrågor och o default inte funkar kan man göra sin mappning som en egen select...

Glöm inte att man behöver INSERT och UPDATE också.

[Joakim Ohlrogge]

Aldrig update :P

Man kan argumentera för att insert och update är en helt annan best och kanske inte hanteras bäst av samma sak som hanterar read men... insert och update kan du väl också få i micromappern :) ... (känns som om den börjar ringas in av den delen av scalaquery som Henrik Johansson talade sig varm om tidigare i tråden)

äh, screw it, kör på map's som i clojure. Vad ska vi med objekt till egentligen... :)

-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
Twitter: @johlrogge
E-mail: joakim....@agical.se

2011/12/2 Mikael Ståldal <mikael....@appearnetworks.com>

2011/12/2 Joakim Ohlrogge <joakim....@agical.com>

[Mats Henricson]

VMD + KDVLMT ?

Mats

2011/12/1 √iktor Ҡlang <viktor...@gmail.com>

CQRS + ES

2011/12/1 Joakim Ohlrogge <joakim....@agical.com>

Då vet man vilket problem man försöker lösa med en ORM. Är en ORM det lättaste sättet att lösa det problemet och är man medveten om vilka andra problem man skaffar sig?

-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
Twitter: @johlrogge
E-mail: joakim....@agical.se

2011/12/1 Mikael Ståldal <mikael....@appearnetworks.com>

2011/12/1 Joakim Ohlrogge <joakim....@agical.com>

En orm löser som jag ser det två saker.

1. Databasoberoende (nåja. Nästan ) 

1: problemet försvinner inte. Det ändrar form. Och handen på hjärtat. Hur ofta byter man egentligen?

Om man bygger en produkt som olika kunder använder med olika relationsdatabaser så är databasoberoende väldigt viktigt.

--

Mikael Ståldal

Senior Software Engineer Appear Kista Science Tower 164 51 Kista Sweden Phone: + 46 (0)8 545 91 572 Mobile: + 46 (0)70 1479581 Email: mikael.staldal@appearnetworks.com Visit us at: www.appearnetworks.com

--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.

Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.

--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.

--
Viktor Klang

Akka Tech Lead

Typesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

[Mikael Ståldal]

2011/12/2 Joakim Ohlrogge <joakim....@agical.com>

Aldrig update :P

Man kan argumentera för att insert och update är en helt annan best och kanske inte hanteras bäst av samma sak som hanterar read men... insert och update kan du väl också få i micromappern :) ... (känns som om den börjar ringas in av den delen av scalaquery som Henrik Johansson talade sig varm om tidigare i tråden)

Jag skulle säga att UPDATE och INSERT är viktigast, för det är det som är jobbigast att göra manuellt. Och så vill man ju gärna att de är i sync med SELECT.

äh, screw it, kör på map's som i clojure. Vad ska vi med objekt till egentligen... :)

I ett statiskt typat språk som Scala så riskerar man ju missa en del av typsäkerheten om man bara kör med map's.

[√iktor Ҡlang]

INSERT och SELECT är det enda som är absolut nödvändigt.

2011/12/2 Mikael Ståldal <mikael....@appearnetworks.com>

--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.

[Olle Kullberg]

"Aldrig UPDATE" ??

Förtydligande: Jag tror att det herrarna menar med att man inte ska köra UPDATE är att man kan göra INSERT istället varje gång man uppdaterar, fast man har en högre version på aggregatet. Sen när man gör SELECT så väljer man helt enkelt den version som är högst. 

/o!!e

2011/12/2 Mikael Ståldal <mikael....@appearnetworks.com>

[Olle Kullberg]

Däremot måste man ha DELETE, annars bryter man mot PUL. (Skärpning Viktor :-) 

2011/12/2 Olle Kullberg <olle.k...@gmail.com>

[Orjan Lundberg]

Man bryter inte bara mot PUL, det finns ju en hel bunt lagar att ta hänsyn tll. 

Någon annan här som jobbar med Erwin modeller och har 10 talet olika språk och skumma 4gl apps som kör mot er databas och krav på att databasen skall leva en produktlivscykel på 40 år? 

Sen olle: Jag antar att det är Polisen är nog de som gallrar sina register sämst av alla. 

Någon annan som har sett detta med SLICK som verkar vara på G: 

Örjan 

2011/12/2 Olle Kullberg <olle.k...@gmail.com>

--
... -.-. .- .-.. .- / .-. ..- .-.. . ...
Orjan Lundberg Phone: +46 702528977  ,SKYPE: orjan_lundberg

[√iktor Ҡlang]

man behöver inte ha det i API:et, man kan ha delete som management i datastoren

[John Nilsson]

Men om man bara kör enkel CRUD varför blanda in en relationel databas?

Sen är det kanske symtom på något annat att ha så många ändringar i en update att man har svårt att få rätt på det.

Mvh,
John

[Olle Kullberg]

Jag tror att de flesta applikationer är 85% CRUD och 15% avancerade operationer. Anledningen att man traditionellt har använt relationsdatabaser är för att klara av de där sista 15%, plus att databasen även används som DW (i de fall man inte haft budget för ett separat DW).

/o!!e

2011/12/2 John Nilsson <jo...@milsson.nu>

[John Nilsson]

Been there. Done that. Tänker inte sätt mig i den sitsen igen. De där sista 15% behöver ändå så mycket speciallösningar för att funka att det inte spelar någon roll att det sker i samma databas. Det lilla man möjligtvis underlättar äts mångfallt upp av komplexiteten i att underhålla ett antal villt skillda modeller och systemkomponenter i samma datstruktur.

Mvh,
John