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.
>
This is a fork of Querulous-generic (Querulous-generic is in turn a fork of the Twitter version). This fork will:
The more advanced features (timeout and so on) probably don't work, since I had to smash some code to get here.
-------------------
/0113+1
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.
En orm löser som jag ser det tvĂ„ saker.1. Databasoberoende (nĂ„ja. NĂ€stan )Â
Om man bygger en produkt som olika kunder anvÀnder med olika relationsdatabaser sÄ Àr databasoberoende vÀldigt viktigt.1: problemet försvinner inte. Det Àndrar form. Och handen pÄ hjÀrtat. Hur ofta byter man egentligen?
Mikael StÄldal |
Senior Software Engineer |
--
Det hÀr meddelandet skickas till dig eftersom du prenumererar pÄ gruppen scala-sverige i Google Groups.
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?
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
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>
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
>
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
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.
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
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.
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
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?
* 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.
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.
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.
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.
--
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.
--
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?
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...
foo.Bar och baz.Bar clash, sÄ du mÄste göra name-mangling
klassnamnet innefattar ju paketet. sÄ fort man kortar sÄ skÀr man hörn
Absolut, sÄ lÀnge inte Àpplen och pÀron blandas, dvs fail early.
Jo givet att allt har samma namn Àr det sista att optimera bortselect * from MyType"select * from " + classOf[MyType].simpleNametypdef readQuery[T](implicit m:Manifest[T]) = "select * from "+m.erasure.simpleNameeller nÄgot. Dvs, man kan utogenerera defaultfrÄgor och o default inte funkar kan man göra sin mappning som en egen select...
2011/12/2 Joakim Ohlrogge <joakim....@agical.com>
CQRS + ES2011/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 )Â
Om man bygger en produkt som olika kunder anvÀnder med olika relationsdatabaser sÄ Àr databasoberoende vÀldigt viktigt.1: problemet försvinner inte. Det Àndrar form. Och handen pÄ hjÀrtat. Hur ofta byter man egentligen?
--
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
--
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
Aldrig update :PMan 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... :)
--
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.
man behöver inte ha det i API:et, man kan ha delete som management i datastoren
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
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