The principal reason I'm using Hibernate is because the base JPA
unfortunately doesn't provide support for non-standard type
persistence, and so a few of my entities are annotated with @Type in
order to use custom mappings for some of the org.joda.time classes
(the Order object in question being
Hi Derek,
this is looking good
On Wed, Sep 10, 2008 at 2:55 AM, Derek Chen-Becker [EMAIL PROTECTED]wrote:
OK, the code is merged in and the latest version is attached. I made a few
minor modifications to the JPA code that Oliver sent:
1. I made the openEM and closeEM methods abstract and
Out of interest, I tried playing around with hibernate-validator on
this demo to see if it works, and (as you can see below), it doesnt.
Any ideas why its doing this?
Looking at the compiled bytecode, its trying to invoke the synthesized
method name_$eq(String x$1), and for some reason, failing
Or just write a PropertyAccessor implementation for Scala vars?
That should do the trick.
Cheers,
Viktor
On Wed, Sep 10, 2008 at 3:22 PM, Derek Chen-Becker [EMAIL PROTECTED]wrote:
Two lines lower it looks like it's trying to fetch the value
(ClassValidator.getMemberValue), but name_$eq is the
That possibility had occurred to me. Perhaps the best thing is just to
create a separate object for the persistence context that defines both
persistence transaction operations. You'd then have implementations
for both JTA and RESOURCE_LOCAL type persistence units and store that
in the
Thanks for pointing that out. I usually use JTA-enabled datasources so I
don't muck around with UserTransaction directly that much.
Derek
On Wed, Sep 10, 2008 at 2:23 PM, Martin Ellis [EMAIL PROTECTED] wrote:
On Wed, Sep 10, 2008 at 4:27 PM, Kris Nuttycombe
[EMAIL PROTECTED] wrote:
The
Man, I really wish I understood the Scala type system better.
def list(xhtml : NodeSeq) : NodeSeq = {
val orders = EM.createQuery[Order](FROM Order).getResultList
orders.flatMap(order =
bind(order, xhtml,
id -- Text(order.getId.toString),
uuid --
Thanks a lot, Martin. That's definitely useful to know, and, wow...
too much magic.
On Wed, Sep 10, 2008 at 2:23 PM, Martin Ellis [EMAIL PROTECTED] wrote:
On Wed, Sep 10, 2008 at 4:27 PM, Kris Nuttycombe
[EMAIL PROTECTED] wrote:
The only question I have is thread safety - it doesn't seem
Kris,
Having a template like (slightly changed from your example so the
values to be dynamic):
lift:Hello.orderList
order:id/
order:items
item:name/
item:cost/
/order:items
Group won't work, as it too needs a Seq[Node], an Iterable[Node] just won't do.
Kris, this problem is certainly annoying and stems from the type
differences between Java collections and Scala collections. You need
your items argument to either be a proper Scala collection (Seq or
any of it's
It's ugly, but this works:
(new java.util.ArrayList[Subscription](items)).flatMap(...)
I guess that Scala is uncomfortable imposing order on something that's
not explicitly ordered?
Kris
On Wed, Sep 10, 2008 at 4:23 PM, Kris Nuttycombe
[EMAIL PROTECTED] wrote:
I quickly found out that Group
11 matches
Mail list logo
