Re: Hibernate

Is there some other ORM technology the Scala uses that is better than
Hiberbate?

Cheers, Eric

On 2011-08-11 8:19 AM, chris@thegodcode.net wrote:
> If you must use hibernate, you might look into how play exposes it.
> Personally I avoid it like the plague.
>
> Sent from my Verizon Wireless Phone
>
> ----- Reply message -----
> From: "Eric Kolotyluk"
> Date: Thu, Aug 11, 2011 09:15
> Subject: [scala-user] Hibernate
> To: "scala-user"
>
> Last year I looked into if anyone had any success in using Scala with
> Hibernate (or NHibernate), While some people got things working, it
> seemed too much like a hack, and there was some missing functionality.
>
> I was wonder lately if things have improved and whether or not anyone
> have found better ways to use Hibernate from Scala.
>
> Lately I have found some things I would to do to make my Hibernate-
> based APIs a little better, but Java is missing some crucial things
> like closures.
>
> Cheers, Eric
>
>

When you say 'Hibernate', are you using the Hibernate API or it's JPA API? If you're using JPA you can drop in different providers such as Eclipselink (my personal favorite: http://www.eclipse.org/eclipselink/) or OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it in both web and desktop apps.

Anyway, you might want to clarify what you mean by 'Better'. JPA/Hibernate integrates lots of lessons learned from very talented Java and Database developers. There are 'thinner' ORM frameworks out there, but it probably wouldn't be a good use of your time to adopt one only to find that you need to start hacking in hibernate-like features later on.

Here is a list of some frameworks.

http://stackoverflow.com/questions/1362748/wanted-good-examples-of-scala...

I've been playing with Squeryl and I'm quite happy with it.

On Thu, Aug 11, 2011 at 1:33 PM, Brian Schlining wrote:
> When you say 'Hibernate', are you using the Hibernate API or it's JPA API? If you're using JPA you can drop in different providers such as Eclipselink (my personal favorite: http://www.eclipse.org/eclipselink/) or OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it in both web and desktop apps.
>
> Anyway, you might want to clarify what you mean by 'Better'. JPA/Hibernate integrates lots of lessons learned from very talented Java and Database developers. There are 'thinner' ORM frameworks out there, but it probably wouldn't be a good use of your time to adopt one only to find that you need to start hacking in hibernate-like features later on.
>
> --
> Brian Schlining
>
>
> On Thursday, August 11, 2011 at 8:55 AM, Eric Kolotyluk wrote:
>
>> Is there some other ORM technology the Scala uses that is better than
>> Hiberbate?
>>
>> Cheers, Eric
>>
>> On 2011-08-11 8:19 AM, chris@thegodcode.net (mailto:chris@thegodcode.net) wrote:
>> > If you must use hibernate, you might look into how play exposes it.
>> > Personally I avoid it like the plague.
>
>
>

This link is better:

https://wiki.scala-lang.org/display/SW/Tools+and+Libraries#ToolsandLibra...

On Thu, Aug 11, 2011 at 13:39, Gilberto Garcia wrote:
> Here is a list of some frameworks.
>
> http://stackoverflow.com/questions/1362748/wanted-good-examples-of-scala...
>
> I've been playing with Squeryl and I'm quite happy with it.
>
>
>
> On Thu, Aug 11, 2011 at 1:33 PM, Brian Schlining wrote:
>> When you say 'Hibernate', are you using the Hibernate API or it's JPA API? If you're using JPA you can drop in different providers such as Eclipselink (my personal favorite: http://www.eclipse.org/eclipselink/) or OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it in both web and desktop apps.
>>
>> Anyway, you might want to clarify what you mean by 'Better'. JPA/Hibernate integrates lots of lessons learned from very talented Java and Database developers. There are 'thinner' ORM frameworks out there, but it probably wouldn't be a good use of your time to adopt one only to find that you need to start hacking in hibernate-like features later on.
>>
>> --
>> Brian Schlining
>>
>>
>> On Thursday, August 11, 2011 at 8:55 AM, Eric Kolotyluk wrote:
>>
>>> Is there some other ORM technology the Scala uses that is better than
>>> Hiberbate?
>>>
>>> Cheers, Eric
>>>
>>> On 2011-08-11 8:19 AM, chris@thegodcode.net (mailto:chris@thegodcode.net) wrote:
>>> > If you must use hibernate, you might look into how play exposes it.
>>> > Personally I avoid it like the plague.
>>
>>
>>
>

Defining 'better' will mean explicitly stating your philosophy with
regard to persistence and the role of the data store, and any layer(s)
above it. On that note, I disagree with the philosophy of hibernate,
and because JPA is just a standardized abstraction for persistence
directly based on hibernate, my disagreement extends to JPA. I don't
use it, nor would I choose to. Stated negatively, I eschew:

- lazy load hell / session detachment
- byte code manipulation
- type unsafety (hql/jpql)

Positively, I embrace:

- explicit data retrieval
- straight object construction
- type safety

Your values may differ; choose appropriately.

-chris

On Aug 11, 12:33 pm, Brian Schlining wrote:
> When you say 'Hibernate', are you using the Hibernate API or it's JPA API? If you're using JPA you can drop in different providers such as Eclipselink (my personal favorite:http://www.eclipse.org/eclipselink/) or OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it in both web and desktop apps.
>
> Anyway, you might want to clarify what you mean by 'Better'. JPA/Hibernate integrates lots of lessons learned from very talented Java and Database developers. There are 'thinner' ORM frameworks out there, but it probably wouldn't be a good use of your time to adopt one only to find that you need to start hacking in hibernate-like features later on.
>
> --
> Brian Schlining
>
>
>
>
>
>
>
> On Thursday, August 11, 2011 at 8:55 AM, Eric Kolotyluk wrote:
> > Is there some other ORM technology the Scala uses that is better than
> > Hiberbate?
>
> > Cheers, Eric
>
> > On 2011-08-11 8:19 AM, ch...@thegodcode.net (mailto:ch...@thegodcode.net) wrote:
> > > If you must use hibernate, you might look into how play exposes it.
> > > Personally I avoid it like the plague.

I am using JPA for the most part. I've tried to stay away from Hibernate
specific things as much as possible.

Right now I have methods that take Callable objects and wrap them with a
transaction. I use anonymous inner classes for the Callable objects, but
it would look so much 'better' if I could use closures instead :-)

In general I find there is so much boilerplate stuff surrounding
Hibernate and ORM that it would be nice to use Scala to hide all the
boilerplate.

You you are saying that Eclipselink and OpenJPA are replacement for
Hibernate, not wrappers for it?

Cheers, Eric

On 2011-08-11 9:33 AM, Brian Schlining wrote:
> When you say 'Hibernate', are you using the Hibernate API or it's JPA API? If you're using JPA you can drop in different providers such as Eclipselink (my personal favorite: http://www.eclipse.org/eclipselink/) or OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it in both web and desktop apps.
>
> Anyway, you might want to clarify what you mean by 'Better'. JPA/Hibernate integrates lots of lessons learned from very talented Java and Database developers. There are 'thinner' ORM frameworks out there, but it probably wouldn't be a good use of your time to adopt one only to find that you need to start hacking in hibernate-like features later on.
>

> I am using JPA for the most part. I've tried to stay away from Hibernate
> specific things as much as possible.
IMHO, that's a good choice.
>
> In general I find there is so much boilerplate stuff surrounding
> Hibernate and ORM that it would be nice to use Scala to hide all the
> boilerplate.
Ah yes, I feel your pain. This is where Data Access Objects (DAO) and/or Stateless session beans are your friends. Here's an example of a relatively generic JPA DAO for Java => http://code.google.com/p/vars-redux/source/browse/vars-jpa/src/main/java... . This particular one explicitly manages transactions as in:
DAO dao = new DAO(anEntityManager);
dao.startTransaction();
// Do database stuff
dao.endTransaction();

But there's no reason you can't quickly create a scalified DAO that handles transactions much more gracefully. Someone on this thread showed an example method of that, something like:

def withTransaction[A](a: => A): A = {
startTransaction()
val result = a
endTransaction()
result
}
>
> You you are saying that Eclipselink and OpenJPA are replacement for
> Hibernate, not wrappers for it?
That's correct. They do NOT wrap Hibernate. They are drop-in replacements. Although you may need to configure your persistence.xml differently for different providers.

Cheers and Good Luck

Is there some other Scala-based technology you are hinting at for
persistent storage of objects? I'm curious.

Cheers, Eric

On 2011-08-11 10:50 AM, clewis@novus.com wrote:
> Defining 'better' will mean explicitly stating your philosophy with
> regard to persistence and the role of the data store, and any layer(s)
> above it. On that note, I disagree with the philosophy of hibernate,
> and because JPA is just a standardized abstraction for persistence
> directly based on hibernate, my disagreement extends to JPA. I don't
> use it, nor would I choose to. Stated negatively, I eschew:
>
> - lazy load hell / session detachment
> - byte code manipulation
> - type unsafety (hql/jpql)
>
> Positively, I embrace:
>
> - explicit data retrieval
> - straight object construction
> - type safety
>
> Your values may differ; choose appropriately.
>
> -chris
>
> On Aug 11, 12:33 pm, Brian Schlining wrote:
>> When you say 'Hibernate', are you using the Hibernate API or it's JPA API? If you're using JPA you can drop in different providers such as Eclipselink (my personal favorite:http://www.eclipse.org/eclipselink/) or OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it in both web and desktop apps.
>>
>> Anyway, you might want to clarify what you mean by 'Better'. JPA/Hibernate integrates lots of lessons learned from very talented Java and Database developers. There are 'thinner' ORM frameworks out there, but it probably wouldn't be a good use of your time to adopt one only to find that you need to start hacking in hibernate-like features later on.
>>
>> --
>> Brian Schlining
>>
>>
>>
>>
>>
>>
>>
>> On Thursday, August 11, 2011 at 8:55 AM, Eric Kolotyluk wrote:
>>> Is there some other ORM technology the Scala uses that is better than
>>> Hiberbate?
>>> Cheers, Eric
>>> On 2011-08-11 8:19 AM, ch...@thegodcode.net (mailto:ch...@thegodcode.net) wrote:
>>>> If you must use hibernate, you might look into how play exposes it.
>>>> Personally I avoid it like the plague.

I don't do much work w/ sql stores in scala, but there are options. If I do have to do serious sql, the first library I'd go to will be ScalaQuery, but that will be a shock if you're looking for an ORM. If you must have something more like an ORM, squeryl is probably more your speed.

-chris

On 08/11/2011 05:15 PM, Eric Kolotyluk wrote:

Is there some other Scala-based technology you are hinting at for persistent storage of objects? I'm curious.

Cheers,  Eric

On 2011-08-11 10:50 AM, clewis [at] novus [dot] com" rel="nofollow"> clewis@novus.com wrote:

Defining 'better' will mean explicitly stating your philosophy with
regard to persistence and the role of the data store, and any layer(s)
above it. On that note, I disagree with the philosophy of hibernate,
and because JPA is just a standardized abstraction for persistence
directly based on hibernate, my disagreement extends to JPA. I don't
use it, nor would I choose to. Stated negatively, I eschew:

- lazy load hell / session detachment
- byte code manipulation
- type unsafety (hql/jpql)

Positively, I embrace:

- explicit data retrieval
- straight object construction
- type safety

Your values may differ; choose appropriately.

-chris

On Aug 11, 12:33 pm, Brian Schlining  wrote:

When you say 'Hibernate', are you using the Hibernate API or it's JPA API? If you're using JPA you can drop in different providers such as Eclipselink (my personal favorite:http://www.eclipse.org/eclipselink/) or OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it in both web and desktop apps.

Anyway, you might want to clarify what you mean by 'Better'. JPA/Hibernate integrates lots of lessons learned from very talented Java and Database developers. There are 'thinner' ORM frameworks out there, but it probably wouldn't be a good use of your time to adopt one only to find that you need to start hacking in hibernate-like features later on.

Hi Eric,

I'm developping mirage-scala that is SQL centric database access library.
http://amateras.sourceforge.jp/site/mirage/mirage-scala.html

The core module of Mirage is a written by Java.
However mirage-scala is wraps it and provides the best interface for Scala
to access RDBMS using SQL.

It has SQL template named *2waySQL* that is executable through any
SQL client tools because template directives are written as SQL comment.
So you can test your SQL template easily.

If you are interested in SQL centric approach, mirage-scala might help you.

Regards,

2011/8/12 Eric Kolotyluk :
> Is there some other Scala-based technology you are hinting at for persistent
> storage of objects? I'm curious.
>
> Cheers,  Eric
>
> On 2011-08-11 10:50 AM, clewis@novus.com wrote:
>>
>> Defining 'better' will mean explicitly stating your philosophy with
>> regard to persistence and the role of the data store, and any layer(s)
>> above it. On that note, I disagree with the philosophy of hibernate,
>> and because JPA is just a standardized abstraction for persistence
>> directly based on hibernate, my disagreement extends to JPA. I don't
>> use it, nor would I choose to. Stated negatively, I eschew:
>>
>> - lazy load hell / session detachment
>> - byte code manipulation
>> - type unsafety (hql/jpql)
>>
>> Positively, I embrace:
>>
>> - explicit data retrieval
>> - straight object construction
>> - type safety
>>
>> Your values may differ; choose appropriately.
>>
>> -chris
>>
>> On Aug 11, 12:33 pm, Brian Schlining  wrote:
>>>
>>> When you say 'Hibernate', are you using the Hibernate API or it's JPA
>>> API? If you're using JPA you can drop in different providers such as
>>> Eclipselink (my personal favorite:http://www.eclipse.org/eclipselink/) or
>>> OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it
>>> in both web and desktop apps.
>>>
>>> Anyway, you might want to clarify what you mean by 'Better'.
>>> JPA/Hibernate integrates lots of lessons learned from very talented Java and
>>> Database developers. There are 'thinner' ORM frameworks out there, but it
>>> probably wouldn't be a good use of your time to adopt one only to find that
>>> you need to start hacking in hibernate-like features later on.
>>>
>>> --
>>> Brian Schlining
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thursday, August 11, 2011 at 8:55 AM, Eric Kolotyluk wrote:
>>>>
>>>> Is there some other ORM technology the Scala uses that is better than
>>>> Hiberbate?
>>>> Cheers, Eric
>>>> On 2011-08-11 8:19 AM, ch...@thegodcode.net
>>>> (mailto:ch...@thegodcode.net) wrote:
>>>>>
>>>>> If you must use hibernate, you might look into how play exposes it.
>>>>> Personally I avoid it like the plague.
>

Yes, I think I have seen Mirage before, it looks familiar, thanks for
reminding me :-)

Cheers, Eric

On 2011-08-11 9:06 PM, Naoki Takezoe wrote:
> Hi Eric,
>
> I'm developping mirage-scala that is SQL centric database access library.
> http://amateras.sourceforge.jp/site/mirage/mirage-scala.html
>
> The core module of Mirage is a written by Java.
> However mirage-scala is wraps it and provides the best interface for Scala
> to access RDBMS using SQL.
>
> It has SQL template named *2waySQL* that is executable through any
> SQL client tools because template directives are written as SQL comment.
> So you can test your SQL template easily.
>
> If you are interested in SQL centric approach, mirage-scala might help you.
>
> Regards,
>
> 2011/8/12 Eric Kolotyluk:
>> Is there some other Scala-based technology you are hinting at for persistent
>> storage of objects? I'm curious.
>>
>> Cheers, Eric
>>
>> On 2011-08-11 10:50 AM, clewis@novus.com wrote:
>>> Defining 'better' will mean explicitly stating your philosophy with
>>> regard to persistence and the role of the data store, and any layer(s)
>>> above it. On that note, I disagree with the philosophy of hibernate,
>>> and because JPA is just a standardized abstraction for persistence
>>> directly based on hibernate, my disagreement extends to JPA. I don't
>>> use it, nor would I choose to. Stated negatively, I eschew:
>>>
>>> - lazy load hell / session detachment
>>> - byte code manipulation
>>> - type unsafety (hql/jpql)
>>>
>>> Positively, I embrace:
>>>
>>> - explicit data retrieval
>>> - straight object construction
>>> - type safety
>>>
>>> Your values may differ; choose appropriately.
>>>
>>> -chris
>>>
>>> On Aug 11, 12:33 pm, Brian Schlining wrote:
>>>> When you say 'Hibernate', are you using the Hibernate API or it's JPA
>>>> API? If you're using JPA you can drop in different providers such as
>>>> Eclipselink (my personal favorite:http://www.eclipse.org/eclipselink/) or
>>>> OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it
>>>> in both web and desktop apps.
>>>>
>>>> Anyway, you might want to clarify what you mean by 'Better'.
>>>> JPA/Hibernate integrates lots of lessons learned from very talented Java and
>>>> Database developers. There are 'thinner' ORM frameworks out there, but it
>>>> probably wouldn't be a good use of your time to adopt one only to find that
>>>> you need to start hacking in hibernate-like features later on.
>>>>
>>>> --
>>>> Brian Schlining
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thursday, August 11, 2011 at 8:55 AM, Eric Kolotyluk wrote:
>>>>> Is there some other ORM technology the Scala uses that is better than
>>>>> Hiberbate?
>>>>> Cheers, Eric
>>>>> On 2011-08-11 8:19 AM, ch...@thegodcode.net
>>>>> (mailto:ch...@thegodcode.net) wrote:
>>>>>> If you must use hibernate, you might look into how play exposes it.
>>>>>> Personally I avoid it like the plague.
>
>

Ideally I do not want to have to use SQL at all, which is one reason I like Hibernate. I was playing with ORM technology back the early 90's while a grad student. I learned SQL back in 1976, and while I know how to use it, I only like using it when I need to do some sophisticated queries. ORM keeps things simple when they should be simple.

Thanks for references,

Cheers, Eric

On 2011-08-11 3:31 PM, Chris Lewis wrote:

4E445839 [dot] 8050708 [at] novus [dot] com" type="cite"> I don't do much work w/ sql stores in scala, but there are options. If I do have to do serious sql, the first library I'd go to will be ScalaQuery, but that will be a shock if you're looking for an ORM. If you must have something more like an ORM, squeryl is probably more your speed.

-chris

On 08/11/2011 05:15 PM, Eric Kolotyluk wrote:

Is there some other Scala-based technology you are hinting at for persistent storage of objects? I'm curious.

Cheers,  Eric

On 2011-08-11 10:50 AM, clewis [at] novus [dot] com" rel="nofollow"> clewis@novus.com wrote:

Defining 'better' will mean explicitly stating your philosophy with
regard to persistence and the role of the data store, and any layer(s)
above it. On that note, I disagree with the philosophy of hibernate,
and because JPA is just a standardized abstraction for persistence
directly based on hibernate, my disagreement extends to JPA. I don't
use it, nor would I choose to. Stated negatively, I eschew:

- lazy load hell / session detachment
- byte code manipulation
- type unsafety (hql/jpql)

Positively, I embrace:

- explicit data retrieval
- straight object construction
- type safety

Your values may differ; choose appropriately.

-chris

On Aug 11, 12:33 pm, Brian Schliningbschlin [dot] [dot] [dot] [at] gmail [dot] com" rel="nofollow"><bschlin...@gmail.com>  wrote:

When you say 'Hibernate', are you using the Hibernate API or it's JPA API? If you're using JPA you can drop in different providers such as Eclipselink (my personal favorite:http://www.eclipse.org/eclipselink/) or OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it in both web and desktop apps.

Anyway, you might want to clarify what you mean by 'Better'. JPA/Hibernate integrates lots of lessons learned from very talented Java and Database developers. There are 'thinner' ORM frameworks out there, but it probably wouldn't be a good use of your time to adopt one only to find that you need to start hacking in hibernate-like features later on.

--
Brian Schlining







On Thursday, August 11, 2011 at 8:55 AM, Eric Kolotyluk wrote:

Is there some other ORM technology the Scala uses that is better than
Hiberbate?
Cheers, Eric
On 2011-08-11 8:19 AM, ch [dot] [dot] [dot] [at] thegodcode [dot] net" rel="nofollow"> ch...@thegodcode.net (ch [dot] [dot] [dot] [at] thegodcode [dot] net" rel="nofollow">mailto:ch...@thegodcode.net) wrote:

If you must use hibernate, you might look into how play exposes it.
Personally I avoid it like the plague.

--
Chris Lewis | Software Engineer Novus Partners Inc | 130 East 59th Street | New York, NY 10022 212.586.3030 | Fax: 646.862.8754 | clewis [at] novus [dot] com" rel="nofollow"> clewis@novus.com

This e-mail message, and any attachments, is intended only for the use of the individual or entity identified in the alias address of this message and may contain information that is confidential, privileged and subject to legal restrictions and penalties regarding its unauthorized disclosure and use. Any unauthorized review, copying, disclosure, use or distribution is strictly prohibited. If you have received this e-mail message in error, please notify the sender immediately by reply e-mail and delete this message, and any attachments, from your system. Thank you.

https://wiki.scala-lang.org/display/SW/Tools+and+Libraries#ToolsandLibra...

Please serve yourself
Cheers!

Ivano

p.s. if you would appreciate a larger choice (but alas, not
necessarily scala-fied) of persistency options, have a look at
http://nosql-database.org/

On Aug 11, 11:15 pm, Eric Kolotyluk wrote:
> Is there some other Scala-based technology you are hinting at for
> persistent storage of objects? I'm curious.
>
> Cheers,  Eric
>
> On 2011-08-11 10:50 AM, cle...@novus.com wrote:
>
>
>
>
>
>
>
> > Defining 'better' will mean explicitly stating your philosophy with
> > regard to persistence and the role of the data store, and any layer(s)
> > above it. On that note, I disagree with the philosophy of hibernate,
> > and because JPA is just a standardized abstraction for persistence
> > directly based on hibernate, my disagreement extends to JPA. I don't
> > use it, nor would I choose to. Stated negatively, I eschew:
>
> > - lazy load hell / session detachment
> > - byte code manipulation
> > - type unsafety (hql/jpql)
>
> > Positively, I embrace:
>
> > - explicit data retrieval
> > - straight object construction
> > - type safety
>
> > Your values may differ; choose appropriately.
>
> > -chris
>
> > On Aug 11, 12:33 pm, Brian Schlining  wrote:
> >> When you say 'Hibernate', are you using the Hibernate API or it's JPA API? If you're using JPA you can drop in different providers such as Eclipselink (my personal favorite:http://www.eclipse.org/eclipselink/) or OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it in both web and desktop apps.
>
> >> Anyway, you might want to clarify what you mean by 'Better'. JPA/Hibernate integrates lots of lessons learned from very talented Java and Database developers. There are 'thinner' ORM frameworks out there, but it probably wouldn't be a good use of your time to adopt one only to find that you need to start hacking in hibernate-like features later on.
>
> >> --
> >> Brian Schlining
>
> >> On Thursday, August 11, 2011 at 8:55 AM, Eric Kolotyluk wrote:
> >>> Is there some other ORM technology the Scala uses that is better than
> >>> Hiberbate?
> >>> Cheers, Eric
> >>> On 2011-08-11 8:19 AM, ch...@thegodcode.net (mailto:ch...@thegodcode.net) wrote:
> >>>> If you must use hibernate, you might look into how play exposes it.
> >>>> Personally I avoid it like the plague.

There is Activate as an alternative to Hibernate too. Is written in scala.
https://github.com/fwbrasil/activate
-- 
Flávio W. Brasilfwbrasil.net

On sexta-feira, 12 de agosto de 2011 at 01:06, Naoki Takezoe wrote:

Hi Eric,

I'm developping mirage-scala that is SQL centric database access library.
http://amateras.sourceforge.jp/site/mirage/mirage-scala.html

The core module of Mirage is a written by Java.
However mirage-scala is wraps it and provides the best interface for Scala
to access RDBMS using SQL.

It has SQL template named *2waySQL* that is executable through any
SQL client tools because template directives are written as SQL comment.
So you can test your SQL template easily.

If you are interested in SQL centric approach, mirage-scala might help you.

Regards,

2011/8/12 Eric Kolotyluk <eric.kolotyluk@gmail.com>:

Is there some other Scala-based technology you are hinting at for persistent
storage of objects? I'm curious.

Cheers,  Eric

On 2011-08-11 10:50 AM, clewis@novus.com wrote:

Defining 'better' will mean explicitly stating your philosophy with
regard to persistence and the role of the data store, and any layer(s)
above it. On that note, I disagree with the philosophy of hibernate,
and because JPA is just a standardized abstraction for persistence
directly based on hibernate, my disagreement extends to JPA. I don't
use it, nor would I choose to. Stated negatively, I eschew:

- lazy load hell / session detachment
- byte code manipulation
- type unsafety (hql/jpql)

Positively, I embrace:

- explicit data retrieval
- straight object construction
- type safety

Your values may differ; choose appropriately.

-chris

On Aug 11, 12:33 pm, Brian Schlining<bschlin...@gmail.com>  wrote:

When you say 'Hibernate', are you using the Hibernate API or it's JPA
API? If you're using JPA you can drop in different providers such as
Eclipselink (my personal favorite:http://www.eclipse.org/eclipselink/) or
OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it
in both web and desktop apps.

Anyway, you might want to clarify what you mean by 'Better'.
JPA/Hibernate integrates lots of lessons learned from very talented Java and
Database developers. There are 'thinner' ORM frameworks out there, but it
probably wouldn't be a good use of your time to adopt one only to find that
you need to start hacking in hibernate-like features later on.

--
Brian Schlining







On Thursday, August 11, 2011 at 8:55 AM, Eric Kolotyluk wrote:

Is there some other ORM technology the Scala uses that is better than
Hiberbate?
Cheers, Eric
On 2011-08-11 8:19 AM, ch...@thegodcode.net
(mailto:ch...@thegodcode.net) wrote:

If you must use hibernate, you might look into how play exposes it.
Personally I avoid it like the plague.

--
Naoki Takezoe

Out of the Scala ORM frameworks I find Anorm the most interesting. 
I'm still not sure how it will pan out in the long-term, but for now it is interesting to keep an eye on :-)



2011/8/13 Flávio W. Brasil <fwbrasil@gmail.com>

There is Activate as an alternative to Hibernate too. Is written in scala.
https://github.com/fwbrasil/activate
-- 
Flávio W. Brasilfwbrasil.net

On sexta-feira, 12 de agosto de 2011 at 01:06, Naoki Takezoe wrote:

Hi Eric,

I'm developping mirage-scala that is SQL centric database access library.
http://amateras.sourceforge.jp/site/mirage/mirage-scala.html

The core module of Mirage is a written by Java.
However mirage-scala is wraps it and provides the best interface for Scala
to access RDBMS using SQL.

It has SQL template named *2waySQL* that is executable through any
SQL client tools because template directives are written as SQL comment.
So you can test your SQL template easily.

If you are interested in SQL centric approach, mirage-scala might help you.

Regards,

2011/8/12 Eric Kolotyluk <eric.kolotyluk@gmail.com>:

Is there some other Scala-based technology you are hinting at for persistent
storage of objects? I'm curious.

Cheers,  Eric

On 2011-08-11 10:50 AM, clewis@novus.com wrote:

Defining 'better' will mean explicitly stating your philosophy with
regard to persistence and the role of the data store, and any layer(s)
above it. On that note, I disagree with the philosophy of hibernate,
and because JPA is just a standardized abstraction for persistence
directly based on hibernate, my disagreement extends to JPA. I don't
use it, nor would I choose to. Stated negatively, I eschew:

- lazy load hell / session detachment
- byte code manipulation
- type unsafety (hql/jpql)

Positively, I embrace:

- explicit data retrieval
- straight object construction
- type safety

Your values may differ; choose appropriately.

-chris

On Aug 11, 12:33 pm, Brian Schlining<bschlin...@gmail.com>  wrote:

When you say 'Hibernate', are you using the Hibernate API or it's JPA
API? If you're using JPA you can drop in different providers such as
Eclipselink (my personal favorite:http://www.eclipse.org/eclipselink/) or
OpenJPA (http://openjpa.apache.org/). JPA works great with Scala; I use it
in both web and desktop apps.

Anyway, you might want to clarify what you mean by 'Better'.
JPA/Hibernate integrates lots of lessons learned from very talented Java and
Database developers. There are 'thinner' ORM frameworks out there, but it
probably wouldn't be a good use of your time to adopt one only to find that
you need to start hacking in hibernate-like features later on.

--
Brian Schlining







On Thursday, August 11, 2011 at 8:55 AM, Eric Kolotyluk wrote:

Is there some other ORM technology the Scala uses that is better than
Hiberbate?
Cheers, Eric
On 2011-08-11 8:19 AM, ch...@thegodcode.net
(mailto:ch...@thegodcode.net) wrote:

If you must use hibernate, you might look into how play exposes it.
Personally I avoid it like the plague.

--
Naoki Takezoe

In some parts of the world, Hibernate is now feared more than the plague, and citizens are quarantined should they show any early signs of Hibernate exposure

To: scala-user@googlegroups.com
From: chris@thegodcode.net
Subject: Re: [scala-user] Hibernate
Date: Thu, 11 Aug 2011 11:19:25 -0400

If you must use hibernate, you might look into how play exposes it. Personally I avoid it like the plague.

That's just ridiculous. Hibernate isn't perfect, but for many
applications it is a perfectly satisfactory tool. In fact, using the
JPA annotations, it's trivially easy to use.

On Wed, Aug 17, 2011 at 4:20 AM, Chris Marshall wrote:
> In some parts of the world, Hibernate is now feared more than the plague,
> and citizens are quarantined should they show any early signs of Hibernate
> exposure
>
> ________________________________
> To: scala-user@googlegroups.com
> From: chris@thegodcode.net
> Subject: Re: [scala-user] Hibernate
> Date: Thu, 11 Aug 2011 11:19:25 -0400
>
> If you must use hibernate, you might look into how play exposes it.
> Personally I avoid it like the plague.

I have never met someone who uses Hibernate who hasn't lost days, if not weeks, of time further down the line, ploughing through incomprehensible stack traces and trying to understand what on earth is going on with the cascading behaviour. And the stale object exceptions. And the fact that the app is so slow.
So; it's not really ridiculous, from the perspective of using time wisely, understanding the technology you depend on and having control over it.
C

> Date: Wed, 17 Aug 2011 10:57:54 -0400
> Subject: Re: [scala-user] Hibernate
> From: dmclean62@gmail.com
> To: scala-user@googlegroups.com
>
> That's just ridiculous. Hibernate isn't perfect, but for many
> applications it is a perfectly satisfactory tool. In fact, using the
> JPA annotations, it's trivially easy to use.
>
> On Wed, Aug 17, 2011 at 4:20 AM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:
> > In some parts of the world, Hibernate is now feared more than the plague,
> > and citizens are quarantined should they show any early signs of Hibernate
> > exposure
> >
> > ________________________________
> > To: scala-user@googlegroups.com
> > From: chris@thegodcode.net
> > Subject: Re: [scala-user] Hibernate
> > Date: Thu, 11 Aug 2011 11:19:25 -0400
> >
> > If you must use hibernate, you might look into how play exposes it.
> > Personally I avoid it like the plague.

I've had a lot of experience with Hibernate over the years and have
used it successfully on a few Scala projects. I would almost always
choose to use it for typical enterprise projects with a web front end
going against a SQL backend. It saves a ton of code.

There's a lot of ways to use it incorrectly and get yourself into
trouble. The main reason is that it's just a huge API. As one
measure, the "bible" of Hibernate (the book "Java Persistence with
Hibernate") is 904 pages and there is no fluff in there. I think JPA
(specifically annotation based mapping) and the Spring annotation
based transaction support have made it a lot easier to use, but I feel
badly for new developers -- the learning curve is steep. But to
use it successfully you only need to use about 25% of its features in
a very constrained way. It's really about knowing what NOT to use.

Very interesting. Thanks for the information :-)

It is a fascinating trade-off we make - the ability to write less actual
new code by leveraging technologies like hibernate - and the (sometimes
very) steep learning curve of adopting the new technology, and
troubleshooting things when they go wrong. With all the reflection going
on in Hibernate, it is frustrating at times trying to troubleshoot stuff
at run-time. Who knows, maybe someday languages like Scala (and beyond)
will be able to check at compile-time more of the Hibernate-like issues
that happen at run-time.

In the same vein, I really like Scala and can write proficient code with
it, but again the learning curve is steep and I will never grok it.
Also, it is very easy for clever people to write Scala code I don't have
a hope in hell of ever understanding - consequently, such code would be
unmaintainable from my perspective.

Basically I am still looking for an excuse to use Scala at work in a
real project, but have not found a project yet where I would feel
comfortable championing others to also learn and use Scala. In short,
while I can write Scala code, I know many of my colleagues who would see
it as a huge barrier. If there were an easy and reliable way to share
common Scala code between Java and .NET that might be a good excuse
because I am tired of having to switch back and forth between Java and
C#. Somehow the Scala for .NET does not seem to be robust enough yet to
do that.

Cheers, Eric

On 2011-08-17 11:08 AM, ericacm wrote:
> I've had a lot of experience with Hibernate over the years and have
> used it successfully on a few Scala projects. I would almost always
> choose to use it for typical enterprise projects with a web front end
> going against a SQL backend. It saves a ton of code.
>
> There's a lot of ways to use it incorrectly and get yourself into
> trouble. The main reason is that it's just a huge API. As one
> measure, the "bible" of Hibernate (the book "Java Persistence with
> Hibernate") is 904 pages and there is no fluff in there. I think JPA
> (specifically annotation based mapping) and the Spring annotation
> based transaction support have made it a lot easier to use, but I feel
> badly for new developers -- the learning curve is steep. But to
> use it successfully you only need to use about 25% of its features in
> a very constrained way. It's really about knowing what NOT to use.
>

Yeech, 904 pages!
From what you've said, though, it seems that Hibernate is basically hideously bloated.
A product in which 75% of the features are rarely or never used is not great in my  opinion.
Spring is one of my pet hates. Not because I dislike the idea of dependencyinjection (I get why that's good, for sure) but because of the "Magic" it uses to wire code in such a way that WTF is heard frequently :-)

On 17 August 2011 20:08, ericacm <ericacm@gmail.com> wrote:

I've had a lot of experience with Hibernate over the years and have
used it successfully on a few Scala projects.  I would almost always
choose to use it for typical enterprise projects with a web front end
going against a SQL backend.   It saves a ton of code.

There's a lot of ways to use it incorrectly and get yourself into
trouble.  The main reason is that it's just a huge API.   As one
measure, the "bible" of Hibernate (the book "Java Persistence with
Hibernate") is 904 pages and there is no fluff in there.   I think JPA
(specifically annotation based mapping) and the Spring annotation
based transaction support have made it a lot easier to use, but I feel
badly for new developers -- the learning curve is steep.     But to
use it successfully you only need to use about 25% of its features in
a very constrained way.   It's really about knowing what NOT to use.

On Wed, Aug 17, 2011 at 7:20 PM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

I have never met someone who uses Hibernate who hasn't lost days, if not weeks, of time further down the line, ploughing through incomprehensible stack traces and trying to understand what on earth is going on with the cascading behaviour. And the stale object exceptions. And the fact that the app is so slow.

I can easily say that I've spend atleast a man-month just debugging Hibernate, and ended up with having to patch it on the outside. But that was years ago, it might be in much better shape today. I'm not an ORM guy anymore.
 

So; it's not really ridiculous, from the perspective of using time wisely, understanding the technology you depend on and having control over it.
C

> Date: Wed, 17 Aug 2011 10:57:54 -0400
> Subject: Re: [scala-user] Hibernate
> From: dmclean62@gmail.com
> To: scala-user@googlegroups.com
>
> That's just ridiculous. Hibernate isn't perfect, but for many
> applications it is a perfectly satisfactory tool. In fact, using the
> JPA annotations, it's trivially easy to use.
>
> On Wed, Aug 17, 2011 at 4:20 AM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:
> > In some parts of the world, Hibernate is now feared more than the plague,
> > and citizens are quarantined should they show any early signs of Hibernate
> > exposure
> >
> > ________________________________
> > To: scala-user@googlegroups.com
> > From: chris@thegodcode.net
> > Subject: Re: [scala-user] Hibernate
> > Date: Thu, 11 Aug 2011 11:19:25 -0400
> >
> > If you must use hibernate, you might look into how play exposes it.
> > Personally I avoid it like the plague.

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I started on a project for a software product about 6 months ago. It
barely worked -- yeah OK, it was a disaster. Thankfully, a clever
colleague of mine joined and took charge (I was simply lamenting,
tryingt to save us in other areas), so there were now two of us shaking
our heads at the situation. That there were now two of us was permission
to fix that shit.

First thing to go: Hibernate -- what a blight that heap of junk is. Next
was Play! and then the rest was the tens of thousands of lines of
Javascript.

Today we use iteratee-based compositional JDBC, with a
planned/half-started type-safe relational query algebra using Scala
2.8.1/Scalaz 6.0.1 running on a (almost -- long story) regular J2EE
container.

This was an enormous improvement. Boy I am glad to be rid of all that
nonsense. Just sayin'. Anyway, we release Monday.

The End.

On 18/08/11 19:26, √iktor Ҡlang wrote:
> On Wed, Aug 17, 2011 at 7:20 PM, Chris Marshall wrote:
>
>> I have never met someone who uses Hibernate who hasn't lost days, if not
>> weeks, of time further down the line, ploughing through incomprehensible
>> stack traces and trying to understand what on earth is going on with the
>> cascading behaviour. And the stale object exceptions. And the fact that the
>> app is so slow.
>>
>
> I can easily say that I've spend atleast a man-month just debugging
> Hibernate, and ended up with having to patch it on the outside. But that was
> years ago, it might be in much better shape today. I'm not an ORM guy
> anymore.
>
>
>>
>> So; it's not really ridiculous, from the perspective of using time wisely,
>> understanding the technology you depend on and having control over it.
>>
>> C
>>
>>> Date: Wed, 17 Aug 2011 10:57:54 -0400
>>
>>> Subject: Re: [scala-user] Hibernate
>>> From: dmclean62@gmail.com
>>
>>> To: scala-user@googlegroups.com
>>>
>>> That's just ridiculous. Hibernate isn't perfect, but for many
>>> applications it is a perfectly satisfactory tool. In fact, using the
>>> JPA annotations, it's trivially easy to use.
>>>
>>> On Wed, Aug 17, 2011 at 4:20 AM, Chris Marshall
>> wrote:
>>>> In some parts of the world, Hibernate is now feared more than the
>> plague,
>>>> and citizens are quarantined should they show any early signs of
>> Hibernate
>>>> exposure
>>>>
>>>> ________________________________
>>>> To: scala-user@googlegroups.com
>>>> From: chris@thegodcode.net
>>>> Subject: Re: [scala-user] Hibernate
>>>> Date: Thu, 11 Aug 2011 11:19:25 -0400
>>>>
>>>> If you must use hibernate, you might look into how play exposes it.
>>>> Personally I avoid it like the plague.
>>
>
>
>

I agree. Hibernate may well be a pain in some ways, but it has a number of advantages over other approaches:
1) You don't (usually) need to resort to SQL. If you do need a specific hand-coded query, then you can use HQL. I think some people forget what writing database independent code is like without ORMs. I use this database independence *all the time*. For some of my projects, the production database is Oracle or MySQL, but my integration tests run with hsqldb or similar. I couldn't do quite a few of my integration tests without hibernate or similar.
2) It is reliable, at least in my experience. When it's not reliable, at least most of the problems are known :-) I can't imagine that any other ORM framework wouldn't have a learning curve associated with it.

I've used Hibernate with Scala, but the data objects are always Java data objects, not Scala ones, for other reasons we shan't go into. Similar experiences with Spring, actually. No problems encountered really.
On Wednesday, 17 August 2011 20:08:53 UTC+2, ericacm wrote:

I've had a lot of experience with Hibernate over the years and have
used it successfully on a few Scala projects.  I would almost always
choose to use it for typical enterprise projects with a web front end
going against a SQL backend.   It saves a ton of code.

There's a lot of ways to use it incorrectly and get yourself into
trouble.  The main reason is that it's just a huge API.   As one
measure, the "bible" of Hibernate (the book "Java Persistence with
Hibernate") is 904 pages and there is no fluff in there.   I think JPA
(specifically annotation based mapping) and the Spring annotation
based transaction support have made it a lot easier to use, but I feel
badly for new developers -- the learning curve is steep.     But to
use it successfully you only need to use about 25% of its features in
a very constrained way.   It's really about knowing what NOT to use.

-- Eric

On Thu, Aug 18, 2011 at 2:13 PM, Matthew Farwell <matthew@farwell.co.uk> wrote:

1) You don't (usually) need to resort to SQL. If you do need a specific hand-coded query, then you can use HQL. I think some people forget what writing database independent code is like without ORMs. I use this database independence *all the time*. For some of my projects, the production database is Oracle or MySQL, but my integration tests run with hsqldb or similar. I couldn't do quite a few of my integration tests without hibernate or similar.

 You don't need to resort to an ORM to get database independence.  ScalaQuery just returns tuples but it provides database independence.
IMHO if you do want an ORM in Scala then the best choice is probably Squeryl.  It gives you the convenience of mapping objects to tables and database independence but unlike hibernate it forces you to provide explicit data retrieval strategies.  See http://squeryl.org/introduction.html#squeryl-control-granularity-more
If you really want to just dump and retrieve entire object graphs then maybe something like mongodb + casbah + salat would be a better option.

Interesting! You're the first person I've seen say anything negative about Play!
Could you maybe sum your opinion of the problems with said framework?
I've been looking at using it myself but I always prefer to know both sides of the coin before making a decision...

On 18 August 2011 13:18, Tony Morris <tonymorris@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I started on a project for a software product about 6 months ago. It
barely worked -- yeah OK, it was a disaster. Thankfully, a clever
colleague of mine joined and took charge (I was simply lamenting,
tryingt to save us in other areas), so there were now two of us shaking
our heads at the situation. That there were now two of us was permission
to fix that shit.

First thing to go: Hibernate -- what a blight that heap of junk is. Next
was Play! and then the rest was the tens of thousands of lines of
Javascript.

Today we use iteratee-based compositional JDBC, with a
planned/half-started type-safe relational query algebra using Scala
2.8.1/Scalaz 6.0.1 running on a (almost -- long story) regular J2EE
container.

This was an enormous improvement. Boy I am glad to be rid of all that
nonsense. Just sayin'. Anyway, we release Monday.

The End.


On 18/08/11 19:26, √iktor Ҡlang wrote:
> On Wed, Aug 17, 2011 at 7:20 PM, Chris Marshall <oxbow_lakes@hotmail.com>wrote:
>
>>  I have never met someone who uses Hibernate who hasn't lost days, if not
>> weeks, of time further down the line, ploughing through incomprehensible
>> stack traces and trying to understand what on earth is going on with the
>> cascading behaviour. And the stale object exceptions. And the fact that the
>> app is so slow.
>>
>
> I can easily say that I've spend atleast a man-month just debugging
> Hibernate, and ended up with having to patch it on the outside. But that was
> years ago, it might be in much better shape today. I'm not an ORM guy
> anymore.
>
>
>>
>> So; it's not really ridiculous, from the perspective of using time wisely,
>> understanding the technology you depend on and having control over it.
>>
>> C
>>
>>> Date: Wed, 17 Aug 2011 10:57:54 -0400
>>
>>> Subject: Re: [scala-user] Hibernate
>>> From: dmclean62@gmail.com
>>
>>> To: scala-user@googlegroups.com
>>>
>>> That's just ridiculous. Hibernate isn't perfect, but for many
>>> applications it is a perfectly satisfactory tool. In fact, using the
>>> JPA annotations, it's trivially easy to use.
>>>
>>> On Wed, Aug 17, 2011 at 4:20 AM, Chris Marshall <oxbow_lakes@hotmail.com>
>> wrote:
>>>> In some parts of the world, Hibernate is now feared more than the
>> plague,
>>>> and citizens are quarantined should they show any early signs of
>> Hibernate
>>>> exposure
>>>>
>>>> ________________________________
>>>> To: scala-user@googlegroups.com
>>>> From: chris@thegodcode.net
>>>> Subject: Re: [scala-user] Hibernate
>>>> Date: Thu, 11 Aug 2011 11:19:25 -0400
>>>>
>>>> If you must use hibernate, you might look into how play exposes it.
>>>> Personally I avoid it like the plague.
>>
>
>
>


- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOTPT9AAoJEPxHMY3rBz0PiZwH/2q2hVfvfq5X/3XJUVxusYUN
mPZdN6/7RxgM8wYkG5v6g1nrjcQUbWnNZpvihZX43nUvGcw15dcKNbMFfD6JniQg
g/Ky2oLAcUtdgU3M5iaOPxWWQjStVjGVwEZQUiXhhzhn6zgu3OpDOJ/U7irbGlTI
OLG9ZI7CdmnhdPH6a0ts2JAFnOnjWi8ziRKa1IjlXiKO9xP5LBg6T3TDPFaBeI8Q
RyjWdRpnQrtL1hnlMjuxyN5n4UOdnU9YWGeq2vlXQKbZtgEm8YmaJywNNSFY+Pnn
TEIGw2SqejVKjkF9RnY6QB9lk/n0gTTYimks3yjLDuiZ1+1/QFGgaP+TFl6JYUU=
=ySrr
-----END PGP SIGNATURE-----

On 08/18/2011 03:13 PM, Matthew Farwell wrote:

I agree. Hibernate may well be a pain in some ways, but it has a number of advantages over other approaches:
1) You don't (usually) need to resort to SQL. If you do need a specific hand-coded query, then you can use HQL. I think some people forget what writing database independent code is like without ORMs. I use this database independence *all the time*. For some of my projects, the production database is Oracle or MySQL, but my integration tests run with hsqldb or similar. I couldn't do quite a few of my integration tests without hibernate or similar.
2) It is reliable, at least in my experience. When it's not reliable, at least most of the problems are known :-) I can't imagine that any other ORM framework wouldn't have a learning curve associated with it.

I've used Hibernate with Scala, but the data objects are always Java data objects, not Scala ones, for other reasons we shan't go into. Similar experiences with Spring, actually. No problems encountered really.

I really thought of not making any comments on this thread as there are many ridiculous claims around. Especially by people not having read any specs on the relevant technology and yet telling everyone how stuff works. But I feel like sharing my positive experience.

I've used Hibernate/JPA with Scala since 2.8 supported nested annotations in beta (and with Java much logner) and have been a happy camper ever since (ok, almost, but my issues have always been resolved by reading docs or asking on relevant forums). All entities are Scala-based too (including using pure Scala-based enums for type-safe constants in entities). The only JPA-related thing I haven't solved using pure Scala is to generate the JPA2's type-safe meta-model classes using Hibernate's hibernate-jpamodelgen artifact. Having it on the classpath makes javac (using java6) use the compiler-plugin to generate the metamodel classes and compile them. Having my entities in Scala this doesn't work of course. Anyone have a solution to this?

The rules of transient objects versus objects in the persistence-context, persist/merge etc. is nothing difficult if you just take time to read the docs.

At least for me, Hibernate and Spring saves me a *lot* of time, especially on maintenance and testing.

If anyone wants to look at an example using Lift+JPA+Hibernate+PostgreSQL look here:
https://www.assembla.com/spaces/liftweb/wiki/JPA_AJAX_303_field-validation_Spring_JTA_XA

Any constructive feedback, including "this is bad because <a thought out principle/pattern etc>...", is of course welcome.

-- 
Andreas Joseph Krogh 
Senior Software Developer / CTO
Public key: http://home.officenet.no/~andreak/public_key.asc
------------------------+---------------------------------------------+
OfficeNet AS            | The most difficult thing in the world is to |
Rosenholmveien 25       | know how to do a thing and to watch         |
1414 Trollåsen          | somebody else doing it wrong, without       |
NORWAY                  | comment.                                    |
Org.nr: NO 981 479 076  |                                             |
                        |                                             |
Tlf:    +47 24 15 38 90 |                                             |
Fax:    +47 24 15 38 91 |                                             |
Mobile: +47 909  56 963 |                                             |
------------------------+---------------------------------------------+

Aren't you at all bothered by HQL's lack of type safety ?

On 18 août, 13:26, Andreas Joseph Krogh
wrote:
> On 08/18/2011 03:13 PM, Matthew Farwell wrote:
>
>
>
>
>
>
>
>
>
> > I agree. Hibernate may well be a pain in some ways, but it has a
> > number of advantages over other approaches:
>
> > 1) You don't (usually) need to resort to SQL. If you do need a
> > specific hand-coded query, then you can use HQL. I think some people
> > forget what writing database independent code is like without ORMs. I
> > use this database independence *all the time*. For some of my
> > projects, the production database is Oracle or MySQL, but my
> > integration tests run with hsqldb or similar. I couldn't do quite a
> > few of my integration tests without hibernate or similar.
>
> > 2) It is reliable, at least in my experience. When it's not reliable,
> > at least most of the problems are known :-) I can't imagine that any
> > other ORM framework wouldn't have a learning curve associated with it.
>
> > I've used Hibernate with Scala, but the data objects are always Java
> > data objects, not Scala ones, for other reasons we shan't go
> > into. Similar experiences with Spring, actually. No problems
> > encountered really.
>
> I really thought of not making any comments on this thread as there are
> many ridiculous claims around. Especially by people not having read any
> specs on the relevant technology and yet telling everyone how stuff
> works. But I feel like sharing my positive experience.
>
> I've used Hibernate/JPA with Scala since 2.8 supported nested
> annotations in beta (and with Java much logner) and have been a happy
> camper ever since (ok, almost, but my issues have always been resolved
> by reading docs or asking on relevant forums). All entities are
> Scala-based too (including using pure Scala-based enums for type-safe
> constants in entities). The only JPA-related thing I haven't solved
> using pure Scala is to generate the JPA2's type-safe meta-model classes
> using Hibernate's hibernate-jpamodelgen artifact. Having it on the
> classpath makes javac (using java6) use the compiler-plugin to generate
> the metamodel classes and compile them. Having my entities in Scala this
> doesn't work of course. Anyone have a solution to this?
>
> The rules of transient objects versus objects in the
> persistence-context, persist/merge etc. is nothing difficult if you just
> take time to read the docs.
>
> At least for me, Hibernate and Spring saves me a *lot* of time,
> especially on maintenance and testing.
>
> If anyone wants to look at an example using
> Lift+JPA+Hibernate+PostgreSQL look here:https://www.assembla.com/spaces/liftweb/wiki/JPA_AJAX_303_field-valid...
>
> Any constructive feedback, including "this is bad because principle/pattern etc>...", is of course welcome.
>
> --
> Andreas Joseph Krogh
> Senior Software Developer / CTO
> Public key:http://home.officenet.no/~andreak/public_key.asc
> ------------------------+---------------------------------------------+
> OfficeNet AS            | The most difficult thing in the world is to |
> Rosenholmveien 25       | know how to do a thing and to watch         |
> 1414 Trollåsen          | somebody else doing it wrong, without       |
> NORWAY                  | comment.                                    |
> Org.nr: NO 981 479 076  |                                             |
>                         |                                             |
> Tlf:    +47 24 15 38 90 |                                             |
> Fax:    +47 24 15 38 91 |                                             |
> Mobile: +47 909  56 963 |                                             |
> ------------------------+---------------------------------------------+

I kind of dislike Hibernate, but did successfully use it for several months, in the code that was a mix of Java and Scala. Yes, had to debug through it to figure out what's up, but it was not all that tragic.

Thanks,
-Vlad


On Wed, Aug 17, 2011 at 10:20 AM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

I have never met someone who uses Hibernate who hasn't lost days, if not weeks, of time further down the line, ploughing through incomprehensible stack traces and trying to understand what on earth is going on with the cascading behaviour. And the stale object exceptions. And the fact that the app is so slow.
So; it's not really ridiculous, from the perspective of using time wisely, understanding the technology you depend on and having control over it.
C

> Date: Wed, 17 Aug 2011 10:57:54 -0400
> Subject: Re: [scala-user] Hibernate
> From: dmclean62@gmail.com
> To: scala-user@googlegroups.com
>
> That's just ridiculous. Hibernate isn't perfect, but for many
> applications it is a perfectly satisfactory tool. In fact, using the
> JPA annotations, it's trivially easy to use.
>
> On Wed, Aug 17, 2011 at 4:20 AM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:
> > In some parts of the world, Hibernate is now feared more than the plague,
> > and citizens are quarantined should they show any early signs of Hibernate
> > exposure
> >
> > ________________________________
> > To: scala-user@googlegroups.com
> > From: chris@thegodcode.net
> > Subject: Re: [scala-user] Hibernate
> > Date: Thu, 11 Aug 2011 11:19:25 -0400
> >
> > If you must use hibernate, you might look into how play exposes it.
> > Personally I avoid it like the plague.

>
>
> Aren't you at all bothered by HQL's lack of type safety ?
>
No

When you say lack of type safety, are you referring to query
parameters?

On Aug 18, 1:36 pm, elem wrote:
> Aren't you at all bothered by HQL's lack of type safety  ?
>
> On 18 août, 13:26, Andreas Joseph Krogh
> wrote:
>
>
>
>
>
>
>
> > On 08/18/2011 03:13 PM, Matthew Farwell wrote:
>
> > > I agree. Hibernate may well be a pain in some ways, but it has a
> > > number of advantages over other approaches:
>
> > > 1) You don't (usually) need to resort to SQL. If you do need a
> > > specific hand-coded query, then you can use HQL. I think some people
> > > forget what writing database independent code is like without ORMs. I
> > > use this database independence *all the time*. For some of my
> > > projects, the production database is Oracle or MySQL, but my
> > > integration tests run with hsqldb or similar. I couldn't do quite a
> > > few of my integration tests without hibernate or similar.
>
> > > 2) It is reliable, at least in my experience. When it's not reliable,
> > > at least most of the problems are known :-) I can't imagine that any
> > > other ORM framework wouldn't have a learning curve associated with it.
>
> > > I've used Hibernate with Scala, but the data objects are always Java
> > > data objects, not Scala ones, for other reasons we shan't go
> > > into. Similar experiences with Spring, actually. No problems
> > > encountered really.
>
> > I really thought of not making any comments on this thread as there are
> > many ridiculous claims around. Especially by people not having read any
> > specs on the relevant technology and yet telling everyone how stuff
> > works. But I feel like sharing my positive experience.
>
> > I've used Hibernate/JPA with Scala since 2.8 supported nested
> > annotations in beta (and with Java much logner) and have been a happy
> > camper ever since (ok, almost, but my issues have always been resolved
> > by reading docs or asking on relevant forums). All entities are
> > Scala-based too (including using pure Scala-based enums for type-safe
> > constants in entities). The only JPA-related thing I haven't solved
> > using pure Scala is to generate the JPA2's type-safe meta-model classes
> > using Hibernate's hibernate-jpamodelgen artifact. Having it on the
> > classpath makes javac (using java6) use the compiler-plugin to generate
> > the metamodel classes and compile them. Having my entities in Scala this
> > doesn't work of course. Anyone have a solution to this?
>
> > The rules of transient objects versus objects in the
> > persistence-context, persist/merge etc. is nothing difficult if you just
> > take time to read the docs.
>
> > At least for me, Hibernate and Spring saves me a *lot* of time,
> > especially on maintenance and testing.
>
> > If anyone wants to look at an example using
> > Lift+JPA+Hibernate+PostgreSQL look here:https://www.assembla.com/spaces/liftweb/wiki/JPA_AJAX_303_field-valid...
>
> > Any constructive feedback, including "this is bad because > principle/pattern etc>...", is of course welcome.
>
> > --
> > Andreas Joseph Krogh
> > Senior Software Developer / CTO
> > Public key:http://home.officenet.no/~andreak/public_key.asc
> > ------------------------+---------------------------------------------+
> > OfficeNet AS            | The most difficult thing in the world is to |
> > Rosenholmveien 25       | know how to do a thing and to watch         |
> > 1414 Trollåsen          | somebody else doing it wrong, without       |
> > NORWAY                  | comment.                                    |
> > Org.nr: NO 981 479 076  |                                             |
> >                         |                                             |
> > Tlf:    +47 24 15 38 90 |                                             |
> > Fax:    +47 24 15 38 91 |                                             |
> > Mobile: +47 909  56 963 |                                             |
> > ------------------------+---------------------------------------------+

On 08/18/2011 07:36 PM, elem wrote:
> Aren't you at all bothered by HQL's lack of type safety ?

No. I use an IDE (IDEA) which understands both HQL and JPAQL and
refactorings are made sucessfully inside queries too. IDEA provides
code-completion and syntax-hilghting inside Strings which represent
those queries, in addition to recognise errors inside them and highlight
them, so it's very easy to work with. When queries are broken due to too
much refactoring I have simple tests (which run using Apache Derby for
speed) reviling what's wrong.

In terms of retrieval strategies, I'm not sure if I understand what
you mean.

By default, Hibernate uses lazy select fetching for collections and
lazy proxy fetching for single-valued associations. But you can
change this per query / per association.

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.h...

On Aug 18, 9:54 am, Robert Wills wrote:
> On Thu, Aug 18, 2011 at 2:13 PM, Matthew Farwell wrote:
>
> > 1) You don't (usually) need to resort to SQL. If you do need a specific
> > hand-coded query, then you can use HQL. I think some people forget what
> > writing database independent code is like without ORMs. I use this database
> > independence *all the time*. For some of my projects, the production
> > database is Oracle or MySQL, but my integration tests run with hsqldb or
> > similar. I couldn't do quite a few of my integration tests without hibernate
> > or similar.
>
> You don't need to resort to an ORM to get database independence.  ScalaQuery
> just returns tuples but it provides database independence.
>
> IMHO if you do want an ORM in Scala then the best choice is probably
> Squeryl.  It gives you the convenience of mapping objects to tables and
> database independence
> but unlike hibernate it forces you to provide explicit data retrieval
> strategies.  Seehttp://squeryl.org/introduction.html#squeryl-control-granularity-more
>
> If you really want to just dump and retrieve entire object graphs then maybe
> something like mongodb + casbah + salat would be a better option.

HQL???

Having been badly burned once with CMP/EJBQL, I won't touch a persistence
manager, ever again. How big is your persistence model and how often does it
change, anyways? It has been my experience that performance is always a
bigger issue than writing that part of the code fast. At least in a
successful product :)

Strait-forward mappers like ibatis are ok...

In my mind, SQL is the only universal standard here :) thus the only one
worth using. Some DSL wrappers like Squeryl are fine, although they allow
the statements to be again placed all over the code and hard to find - less
maintainable in a large code base, that is...

My 2c,
Razie

-----Original Message-----
From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On
Behalf Of ericacm
Sent: August-18-11 2:13 PM
To: scala-user
Subject: [scala-user] Re: Hibernate

In terms of retrieval strategies, I'm not sure if I understand what you
mean.

By default, Hibernate uses lazy select fetching for collections and
lazy proxy fetching for single-valued associations. But you can
change this per query / per association.

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.h...
performance-fetching

On Aug 18, 9:54 am, Robert Wills wrote:
> On Thu, Aug 18, 2011 at 2:13 PM, Matthew Farwell
wrote:
>
> > 1) You don't (usually) need to resort to SQL. If you do need a
> > specific hand-coded query, then you can use HQL. I think some people
> > forget what writing database independent code is like without ORMs.
> > I use this database independence *all the time*. For some of my
> > projects, the production database is Oracle or MySQL, but my
> > integration tests run with hsqldb or similar. I couldn't do quite a
> > few of my integration tests without hibernate or similar.
>
> You don't need to resort to an ORM to get database independence.  
> ScalaQuery just returns tuples but it provides database independence.
>
> IMHO if you do want an ORM in Scala then the best choice is probably
> Squeryl.  It gives you the convenience of mapping objects to tables
> and database independence but unlike hibernate it forces you to
> provide explicit data retrieval strategies.  
> Seehttp://squeryl.org/introduction.html#squeryl-control-granularity-mo
> re
>
> If you really want to just dump and retrieve entire object graphs then
> maybe something like mongodb + casbah + salat would be a better option.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, among many things in Hibernate, it is the source of much disaster.
However, it is not particularly useful to build type-safe query around
hibernate as it currently stands -- you don't gain much -- so you're
unlikely to find too many people who are "bothered" by it, due to the
absence of foreseen utility.

On 19/08/11 03:36, elem wrote:
>
> Aren't you at all bothered by HQL's lack of type safety ?
>
> On 18 août, 13:26, Andreas Joseph Krogh
> wrote:
>> On 08/18/2011 03:13 PM, Matthew Farwell wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> I agree. Hibernate may well be a pain in some ways, but it has a
>>> number of advantages over other approaches:
>>
>>> 1) You don't (usually) need to resort to SQL. If you do need a
>>> specific hand-coded query, then you can use HQL. I think some people
>>> forget what writing database independent code is like without ORMs. I
>>> use this database independence *all the time*. For some of my
>>> projects, the production database is Oracle or MySQL, but my
>>> integration tests run with hsqldb or similar. I couldn't do quite a
>>> few of my integration tests without hibernate or similar.
>>
>>> 2) It is reliable, at least in my experience. When it's not reliable,
>>> at least most of the problems are known :-) I can't imagine that any
>>> other ORM framework wouldn't have a learning curve associated with it.
>>
>>> I've used Hibernate with Scala, but the data objects are always Java
>>> data objects, not Scala ones, for other reasons we shan't go
>>> into. Similar experiences with Spring, actually. No problems
>>> encountered really.
>>
>> I really thought of not making any comments on this thread as there are
>> many ridiculous claims around. Especially by people not having read any
>> specs on the relevant technology and yet telling everyone how stuff
>> works. But I feel like sharing my positive experience.
>>
>> I've used Hibernate/JPA with Scala since 2.8 supported nested
>> annotations in beta (and with Java much logner) and have been a happy
>> camper ever since (ok, almost, but my issues have always been resolved
>> by reading docs or asking on relevant forums). All entities are
>> Scala-based too (including using pure Scala-based enums for type-safe
>> constants in entities). The only JPA-related thing I haven't solved
>> using pure Scala is to generate the JPA2's type-safe meta-model classes
>> using Hibernate's hibernate-jpamodelgen artifact. Having it on the
>> classpath makes javac (using java6) use the compiler-plugin to generate
>> the metamodel classes and compile them. Having my entities in Scala this
>> doesn't work of course. Anyone have a solution to this?
>>
>> The rules of transient objects versus objects in the
>> persistence-context, persist/merge etc. is nothing difficult if you just
>> take time to read the docs.
>>
>> At least for me, Hibernate and Spring saves me a *lot* of time,
>> especially on maintenance and testing.
>>
>> If anyone wants to look at an example using
>> Lift+JPA+Hibernate+PostgreSQL look here:https://www.assembla.com/spaces/liftweb/wiki/JPA_AJAX_303_field-valid...
>>
>> Any constructive feedback, including "this is bad because > principle/pattern etc>...", is of course welcome.
>>
>> --
>> Andreas Joseph Krogh
>> Senior Software Developer / CTO
>> Public key:http://home.officenet.no/~andreak/public_key.asc
>> ------------------------+---------------------------------------------+
>> OfficeNet AS | The most difficult thing in the world is to |
>> Rosenholmveien 25 | know how to do a thing and to watch |
>> 1414 Trollåsen | somebody else doing it wrong, without |
>> NORWAY | comment. |
>> Org.nr: NO 981 479 076 | |
>> | |
>> Tlf: +47 24 15 38 90 | |
>> Fax: +47 24 15 38 91 | |
>> Mobile: +47 909 56 963 | |
>> ------------------------+---------------------------------------------+

I also found that the excellent IntelliJ support for HQL expression editing meant that I really didn't have much trouble with it being untyped from the view of the compiler. The IDE was doing a lot to help me build legal queries. The moral? Compilers are not our only tooling.
Matthew

On 18 August 2011 19:07, Andreas Joseph Krogh <andreas.krogh@gmail.com> wrote:

On 08/18/2011 07:36 PM, elem wrote:
> Aren't you at all bothered by HQL's lack of type safety  ?

No. I use an IDE (IDEA) which understands both HQL and JPAQL and
refactorings are made sucessfully inside queries too. IDEA provides
code-completion and syntax-hilghting inside Strings which represent
those queries, in addition to recognise errors inside them and highlight
them, so it's very easy to work with. When queries are broken due to too
much refactoring I have simple tests (which run using Apache Derby for
speed) reviling what's wrong.

--
Andreas Joseph Krogh <andreak@officenet.no>
Senior Software Developer / CTO
Public key: http://home.officenet.no/~andreak/public_key.asc
------------------------+---------------------------------------------+
OfficeNet AS            | The most difficult thing in the world is to |
Rosenholmveien 25       | know how to do a thing and to watch         |
1414 Trollåsen          | somebody else doing it wrong, without       |
NORWAY                  | comment.                                    |
Org.nr: NO 981 479 076  |                                             |
                       |                                             |
Tlf:    +47 24 15 38 90 |                                             |
Fax:    +47 24 15 38 91 |                                             |
Mobile: +47 909 56 963 |                                             |
------------------------+---------------------------------------------+

--
Dr Matthew PocockVisitor, School of Computing Science, Newcastle Universitymailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozertel: (0191) 2566550mob: +447535664143

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denoting a query in an algebraic data type does more than make it
"safer" (although, I'm sure you have overshot the estimation of just how
safe you really are).

It allows you to take the compositional thesis further into more and
more specialised library code. Even in light of the absence of
first-class algebraic values when using "HQL", you would be brave
(foolish?) to attempt this without safety -- do I need to mention the
existing failed attempts to "abstract HQL"? No, I don't think so.

On 20/08/11 21:31, Matthew Pocock wrote:
> I also found that the excellent IntelliJ support for HQL expression editing
> meant that I really didn't have much trouble with it being untyped from the
> view of the compiler. The IDE was doing a lot to help me build legal
> queries. The moral? Compilers are not our only tooling.
>
> Matthew
>
> On 18 August 2011 19:07, Andreas Joseph Krogh wrote:
>
>> On 08/18/2011 07:36 PM, elem wrote:
>>> Aren't you at all bothered by HQL's lack of type safety ?
>>
>> No. I use an IDE (IDEA) which understands both HQL and JPAQL and
>> refactorings are made sucessfully inside queries too. IDEA provides
>> code-completion and syntax-hilghting inside Strings which represent
>> those queries, in addition to recognise errors inside them and highlight
>> them, so it's very easy to work with. When queries are broken due to too
>> much refactoring I have simple tests (which run using Apache Derby for
>> speed) reviling what's wrong.
>>
>> --
>> Andreas Joseph Krogh
>> Senior Software Developer / CTO
>> Public key: http://home.officenet.no/~andreak/public_key.asc
>> ------------------------+---------------------------------------------+
>> OfficeNet AS | The most difficult thing in the world is to |
>> Rosenholmveien 25 | know how to do a thing and to watch |
>> 1414 Trollåsen | somebody else doing it wrong, without |
>> NORWAY | comment. |
>> Org.nr: NO 981 479 076 | |
>> | |
>> Tlf: +47 24 15 38 90 | |
>> Fax: +47 24 15 38 91 | |
>> Mobile: +47 909 56 963 | |
>> ------------------------+---------------------------------------------+
>>
>>
>
>