David Pollak a écrit :
Folks,
[...]
Over the last couple of years, I've been noticing trends in web
development, in the needs of my various consulting gigs, and in some
other projects. It's clear to me that it's time for a unified data and
data management model that goes beyond OR
This sounds very exciting David, please ensure to keep us posted on any
developments.
This notion of Q's - is this the method by which actors will be
distributed (managed via zookeeper, i would assume)?
Any reference materials you can point me to further whet my appetite?
On Thu, 2009-06-18 at
David,
Amazing, I love your PASSION.
All the best.
Mohan
From: liftweb@googlegroups.com [mailto:lift...@googlegroups.com] On
Behalf Of David Pollak
Sent: 18 June 2009 15:20
To: David Pollak
Subject: [Lift] Lift and Goat Rodeo
Folks,
At the end of the
Dave is there a reason why writes are allowed outside a transaction
boundaries ?
Br's,
Marius
On Jun 18, 10:19 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
Folks,
At the end of the Scala Lift Off, after I finished my third beer, Martin
Odersky came over to me and asked, so, what's
David, that sounds really great.
I tried to think about what's a good approach to be really scalable in
context of data writing/reading (e.g. when you have to write an app
for a huge number of users)
A RDMBS approach would not be sufficient.
Looking forward for further information for this
On Thu, Jun 18, 2009 at 4:23 AM, marius d. marius.dan...@gmail.com wrote:
Dave is there a reason why writes are allowed outside a transaction
boundaries ?
Writes are not allowed outside of transactional boundaries. You have to
enter a transaction to get a TRef, a transactional reference.
On Thu, Jun 18, 2009 at 8:29 AM, TSP tim.pig...@optrak.co.uk wrote:
Hi David,
I am working in the typical business application space, where rdbms
are quite nice solutions - lots of tables but in your application you
never really need an awful lot of rows for anything other than
consolidated
Sorry Dave but something still escapes me.
Transaction.write also takes a TRef parameter which is never used.
Furthermore nothing seems to prevent one to call new TRef... outside a
Transaction.
I assume the normal usage is:
val ref = new Ref(QString())
ref.map(tref = // do transactional reads
Yeah... I haven't sealed things yet. You can do these things... but not for
long. ;-)
On Jun 18, 2009 10:36 AM, marius d. marius.dan...@gmail.com wrote:
Sorry Dave but something still escapes me.
Transaction.write also takes a TRef parameter which is never used.
Furthermore nothing seems to
