[Lift] Re: a plea for documentation
Hi, I also agree with David that I'm very excited to use Lift and have great enthusiasm about it, and I play around with it now and then, but I'm reluctant to use it on my big project until my understanding is at a point of strong confidence. So like a weight lifter, I'm in training. When I compare it to SEAM, SEAM is also complex but there is so much documentation I won't get stuck so I'm willing to use it on the big project. Thanks, Philip On Nov 27, 10:15 am, David Stein [EMAIL PROTECTED] wrote: On Wed, Nov 26, 2008 at 3:10 PM, David Pollak [EMAIL PROTECTED] wrote: If you've been following the threads then you've seen that I'm devoting the next 4 months to Lift 1.0 and documentation. What more do you want? What are you planning to contribute to the process other than complaining that it's somehow not enough? Oops. My apologies for being so irritable. Funny, my girlfriend has also been complaining about me this week, so maybe I'm just oblivious to how I come across! I definitely didn't mean to imply that we need more from the committers, per se, but I might suggest that a highly effective use of their time would be to document the API before writing books, which could take months. Documenting the API is probably 15 hours tops, and with 6-12 committers it's not a lot overall. With the API documented, many of us bewildered folks on the sidelines could step up and write tutorials and sample projects. I have a little egg on my face because I don't think I gave a thorough read-through of the book. I started looking at a few chapters a while ago, but they were more outlines at the time. Somehow I missed the chapters which are actually pretty comprehensive, like the one on JPA. Very much looking forward to this! Sorry again, and please ignore me as necessary, DS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: JPA and Record
But all in all I'm not convinced that this effort really worth it. AFAIC I still don;t get the whole point of integrating Record/Field with JPA. Over the time i've been working with lift there has been much discussion about unified validation, and hooking various persistence backend's. I remember a particular discussion that was had about mapper, and how appropriate it was for use within a large applications, and DPP suggested that mapper was good up until about 20 database tables - I think the phrase was quick and dirty. At the time we had no JPA support what-so-ever and Record seemed like a far away ideal which promised a way of hooking in tech's like JPA and still get all the cool lift features. Now we have Record, it seems like we wouldn't have made a great step forward if mapper is still the only first line persistence mechanism and we still have no abstract way to handle validation? I know record brings a bunch of stuff to the table and its not just mapper on steroids, but it seems like we should be able to provide a way of hooking Record into JPA as there will no doubt be a lot of users that have existing Hibernate and/or JPA tiers and want to use lift - especially within the enterprise space. I cant really suggest a way forward, as I'm no JPA expert, but what i can do is argue for its support and how important it is we provide some level of integration. We know that JPA is a lot more complicated to implement anyway right now in lift, but perhaps we look for a staged approach of implementation? Start by providing something loose, that requires the user to jump through some more hoops, then as time progresses upgrade that support to something more streamlined (and i.e. more complex for us to create)? Just my two cents :) Cheers, Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Using TemplatePf for JPA powered templates
Hey Viktor, If you use Hibernate you could simply configure the L2-cache and have Hibernate manage it for you. (EHCache or whatever cache-provider you like) This means you won't have to manually use the filesystem and can let the cache-provider do what it's good at :) I tried to implement L2 cache before with lift and didnt get very far - perhaps i'll give it another go. My other concern is performance - given a table like: create table tree_items ( id int(11) unsigned not null auto_increment, parent_id int(11) unsigned, name varchar(20), other_content varchar(255), primary key (id) ); where parent_id defines the tree structure, im a little worried that the queries would be come fairly bloated? I also did some looking around to see if there were any examples online of tree structures in JPA but alas could not find anything usefull - it appears its quite problematic...? Cheers Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Using TemplatePf for JPA powered templates
If you're heavily skewed towards reads and not writes (as it seems in the case of a CMS), you might want to look at Celko nested sets: http://www.intelligententerprise.com/001020/celko.jhtml http://dev.mysql.com/tech-resources/articles/hierarchical-data.html A little more work on updates than an adjacency model, but a lot more efficient. Derek On Sun, Nov 30, 2008 at 6:29 AM, Viktor Klang [EMAIL PROTECTED]wrote: Hi Tim! I'm not sure I follow. What do you need the tree-structure for? /Vik On Sun, Nov 30, 2008 at 1:11 PM, Tim Perrett [EMAIL PROTECTED] wrote: Hey Viktor, If you use Hibernate you could simply configure the L2-cache and have Hibernate manage it for you. (EHCache or whatever cache-provider you like) This means you won't have to manually use the filesystem and can let the cache-provider do what it's good at :) I tried to implement L2 cache before with lift and didnt get very far - perhaps i'll give it another go. My other concern is performance - given a table like: create table tree_items ( id int(11) unsigned not null auto_increment, parent_id int(11) unsigned, name varchar(20), other_content varchar(255), primary key (id) ); where parent_id defines the tree structure, im a little worried that the queries would be come fairly bloated? I also did some looking around to see if there were any examples online of tree structures in JPA but alas could not find anything usefull - it appears its quite problematic...? Cheers Tim -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Using TemplatePf for JPA powered templates
Hey viktor, I need the tree structure because it's for this publishing engine I'm writing. The idea is that you could create a page, and that page can have x number of children, and there children cab have children etc etc Does that make sense? Perhaps there is a more intuitive way to do this? Cheers Tim Sent from my iPhone On 30 Nov 2008, at 13:29, Viktor Klang [EMAIL PROTECTED] wrote: Hi Tim! I'm not sure I follow. What do you need the tree-structure for? /Vik On Sun, Nov 30, 2008 at 1:11 PM, Tim Perrett [EMAIL PROTECTED] wrote: Hey Viktor, If you use Hibernate you could simply configure the L2-cache and have Hibernate manage it for you. (EHCache or whatever cache-provider you like) This means you won't have to manually use the filesystem and can let the cache-provider do what it's good at :) I tried to implement L2 cache before with lift and didnt get very far - perhaps i'll give it another go. My other concern is performance - given a table like: create table tree_items ( id int(11) unsigned not null auto_increment, parent_id int(11) unsigned, name varchar(20), other_content varchar(255), primary key (id) ); where parent_id defines the tree structure, im a little worried that the queries would be come fairly bloated? I also did some looking around to see if there were any examples online of tree structures in JPA but alas could not find anything usefull - it appears its quite problematic...? Cheers Tim -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: JPA and Record
The whole point of integrating (and I use the word integrating here loosely)
is so that there's a common form framework for people to use. Really, the
point of Record as far as I can tell is to loosen and/or remove the tight
coupling with the datastore, and in that sense Record is succeeding. As Tim
points out, there are going to be people with existing JPA libraries and
what we're trying to propose is a means for them to leverage their existing
libraries alongside the nice work done in Record. As ugly as the boilerplate
for delegation may seem, I don't see any better solution without adding
significant complexity. I've done bytecode manipulation in the past and
while it can be very handy, it makes things a lot more complex on the
backend and I'm really trying to avoid complexity (this includes a compiler
plugin, too).
Delegation provides the cleanest approach I can come up with; it actually
helps in the case where someone wants to use an existing JPA library because
you could simply wrap an instance and delegate to it:
class MyEntry extends Record[MyEntry] {
var inner : RealEntry = _
object name extends StringField(this) with Delegation
name.delegate(inner.name, inner.name = _)
...
}
By adding a few lines of boilerplate in each class you get validation, form
generation, presentation HTML, JSON representation, etc. It's up to the
end-user to determine whether these features are worth the cost of a few
LoC.
I'm not saying this is a perfect solution, just that I think that this is
the best first cut at it. Also, no one is saying that people have to use JPA
with Record. I'm assuming that the majority of new Lift apps will probably
use Record/Mapper because they're simple, easy to use and quite capable of
handling most data models. But for the people with existing JPA libraries,
or for people who would like to use JPA for the additional features,
compatibility with Java apps, etc, I'd like to have a better answer than an
absolute Don't use Record or Switch to Record.
Derek
On Sun, Nov 30, 2008 at 1:40 AM, Marius [EMAIL PROTECTED] wrote:
I totally agree with you Viktor! ... although it seems like a workable
solution in this case a Record contains to distinct entities to
represent the same data and of course the boilerplate.
It was mentioned above compiler plugins which I expressed my opinion
about it (I'd stay away) but there might be another way to alter the
bytecode at runtime. I'm talking about dynamic class weaving.
Basically it is a class loader that before returning the actual
updated class. Kind of what AspectJ is doing. A while ago a wrote a
bytecode level manipulation framework and combined with a special
classloader I was able to modify a class dynamically and use it.
Of course there are caveats:
1. Complexity induced by bytecode level manipulation
2. How a dynamic class loader cope with container's classloader that
essentially loads the web application. Of course it would delegate the
loading to the container's classloader but these modifiable classes
should probably not live in WEB-INF/classes or WEB-INF/lib folder.
But all in all I'm not convinced that this effort really worth it.
AFAIC I still don;t get the whole point of integrating Record/Field
with JPA. If someone wants to switch easily from JPA to Record or vice-
versa, to have this flexibility perhaps consider to abstract these
layers from the rest of the application and using other persistence
technologies would not affect the application business logic ... but
this is about how the appliation is designed etc.
Br's,
Marius
On Nov 30, 9:56 am, Viktor Klang [EMAIL PROTECTED] wrote:
IMHO:
@Column{val name = my_name}
var name : String = _
object nameField extends StringField(this,100) with Delegated
nameField.delegate(name, name = _)
That's just too much boilerplate. For me, who went to scala to lose
boilerplate, this is not a viable solution.
Unfortunately the JPA spec is kind of weak when it comes to adaptation,
so
my suggestion to make it work with Hibernate first still stands.
What do you guys think?
Cheers,
Viktor
On Sat, Nov 29, 2008 at 10:23 PM, Derek Chen-Becker
[EMAIL PROTECTED]wrote:
No big deal. In the example code I did a by-name in the delegate method
so
at least it's transparent to the end-user.
Derek
On Sat, Nov 29, 2008 at 11:06 AM, Jorge Ortiz [EMAIL PROTECTED]
wrote:
Just wanted to chime in real quick...
type Getter = () = MyType // Can this be by-name in any way?
No. By-names are not first-class types. It's gotta be () = MyType
--j
--
Viktor Klang
Senior Systems Analyst
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
[Lift] Re: JPA and Record
I just thinked again. As I understand, Record like Mapper have no special
support for one-to-many or many-to-many relations. And lazy-loading is used
mostly in such scenarios. So maybe this code is really enough to blend
Record features with JPA's:
object name extends StringField(this,100)
@Column{val name = my_name}
def getName() = name.value
def setName(newVal : String) = name.set(newVal)
Or am I wrong now? And can this work with Mapper too?
Maybe an interesting thing to do as part of JPA integration effort would be
to wrap JPA query language in a typesafe API like one in Mapper. Maybe it is
far easier than to code support for JPA/Hibernate object-oriented query
features in Mapper/Record. What do you think?
On Sun, Nov 30, 2008 at 5:45 PM, Derek Chen-Becker [EMAIL PROTECTED]wrote:
The whole point of integrating (and I use the word integrating here
loosely) is so that there's a common form framework for people to use.
Really, the point of Record as far as I can tell is to loosen and/or remove
the tight coupling with the datastore, and in that sense Record is
succeeding. As Tim points out, there are going to be people with existing
JPA libraries and what we're trying to propose is a means for them to
leverage their existing libraries alongside the nice work done in Record. As
ugly as the boilerplate for delegation may seem, I don't see any better
solution without adding significant complexity. I've done bytecode
manipulation in the past and while it can be very handy, it makes things a
lot more complex on the backend and I'm really trying to avoid complexity
(this includes a compiler plugin, too).
Delegation provides the cleanest approach I can come up with; it actually
helps in the case where someone wants to use an existing JPA library because
you could simply wrap an instance and delegate to it:
class MyEntry extends Record[MyEntry] {
var inner : RealEntry = _
object name extends StringField(this) with Delegation
name.delegate(inner.name, inner.name = _)
...
}
By adding a few lines of boilerplate in each class you get validation, form
generation, presentation HTML, JSON representation, etc. It's up to the
end-user to determine whether these features are worth the cost of a few
LoC.
I'm not saying this is a perfect solution, just that I think that this is
the best first cut at it. Also, no one is saying that people have to use JPA
with Record. I'm assuming that the majority of new Lift apps will probably
use Record/Mapper because they're simple, easy to use and quite capable of
handling most data models. But for the people with existing JPA libraries,
or for people who would like to use JPA for the additional features,
compatibility with Java apps, etc, I'd like to have a better answer than an
absolute Don't use Record or Switch to Record.
Derek
On Sun, Nov 30, 2008 at 1:40 AM, Marius [EMAIL PROTECTED] wrote:
I totally agree with you Viktor! ... although it seems like a workable
solution in this case a Record contains to distinct entities to
represent the same data and of course the boilerplate.
It was mentioned above compiler plugins which I expressed my opinion
about it (I'd stay away) but there might be another way to alter the
bytecode at runtime. I'm talking about dynamic class weaving.
Basically it is a class loader that before returning the actual
updated class. Kind of what AspectJ is doing. A while ago a wrote a
bytecode level manipulation framework and combined with a special
classloader I was able to modify a class dynamically and use it.
Of course there are caveats:
1. Complexity induced by bytecode level manipulation
2. How a dynamic class loader cope with container's classloader that
essentially loads the web application. Of course it would delegate the
loading to the container's classloader but these modifiable classes
should probably not live in WEB-INF/classes or WEB-INF/lib folder.
But all in all I'm not convinced that this effort really worth it.
AFAIC I still don;t get the whole point of integrating Record/Field
with JPA. If someone wants to switch easily from JPA to Record or vice-
versa, to have this flexibility perhaps consider to abstract these
layers from the rest of the application and using other persistence
technologies would not affect the application business logic ... but
this is about how the appliation is designed etc.
Br's,
Marius
On Nov 30, 9:56 am, Viktor Klang [EMAIL PROTECTED] wrote:
IMHO:
@Column{val name = my_name}
var name : String = _
object nameField extends StringField(this,100) with Delegated
nameField.delegate(name, name = _)
That's just too much boilerplate. For me, who went to scala to lose
boilerplate, this is not a viable solution.
Unfortunately the JPA spec is kind of weak when it comes to adaptation,
so
my suggestion to make it work with Hibernate first still stands.
What do you guys think?
Cheers,
Viktor
On Sat,
[Lift] Re: Using TemplatePf for JPA powered templates
IIRC, JPA has support for batch updates, but I'm not 100% positive on that.
I'll have more time tomorrow to look at this if you'd still like to discuss
it.
Derek
On Sun, Nov 30, 2008 at 12:32 PM, Tim Perrett [EMAIL PROTECTED] wrote:
Derek,
Those links are *extremely* good - thank you! I've not really done
anything with tree structures before and they are really, really
usefull.
One thing however, it appears the optimal way of doing the insert
queries would be with stored procedures, however that im not down
with, and ideally, i want to keep database vendor independent (part of
the point of using JPA) so ideally i want to suck that up into the
application logic. For instance:
--START
SELECT @myRight := rgt FROM nested_category WHERE name =
'TELEVISIONS';
UPDATE nested_category SET rgt = rgt + 2 WHERE rgt @myRight;
UPDATE nested_category SET lft = lft + 2 WHERE lft @myRight;
INSERT INTO nested_category(name, lft, rgt) VALUES('GAME CONSOLES',
@myRight + 1, @myRight + 2);
--END
This makes use of variables, and i could of course do this via 3
separate queries in JPA, but i wondered if there was a neater way to
construct this type of thing with JPA?
Any advice you guys have is most welcome
Cheers
Tim
On Nov 30, 2:27 pm, Derek Chen-Becker [EMAIL PROTECTED] wrote:
If you're heavily skewed towards reads and not writes (as it seems in the
case of a CMS), you might want to look at Celko nested sets:
http://www.intelligententerprise.com/001020/celko.jhtml
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
A little more work on updates than an adjacency model, but a lot more
efficient.
Derek
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Testing for well-formed XML
OK, I have a maven-lift plugin done with an i18ngen target that you can use
to parse all of your Scala and xhtml sources for i18n keys (lift:loc, etc).
The question now is, where should I put it? Should I put it in the main lift
repo or just dump it in my own github repo?
Derek
On Fri, Nov 28, 2008 at 7:49 AM, Derek Chen-Becker [EMAIL PROTECTED]wrote:
Yes, I was just reading about writing Maven plugins yesterday for the I18N
tool and it looks like they depend heavily on javadoc-style annontations.
Right now that means the plugin I'm hacking on has a Scala implementation
with essentially a Java shim. I would much prefer to just have a single
scala plugin :)
Derek
On Fri, Nov 28, 2008 at 6:34 AM, Josh Suereth [EMAIL PROTECTED]wrote:
Alright,
My new side project is to be able to write maven plugins in the scala
language. Luckily for us JRuby and Groovy have already done this (although
Groovy took a huge shortcut that JRuby/Scala are unable to use), so I have
some great sample code. Anyway, before I start cranking on this, just
wanted to make sure this is needed/desired for future lift work?
On Thu, Nov 27, 2008 at 10:27 PM, Josh Suereth [EMAIL PROTECTED]wrote:
The maven-scala-plugin is a great place to look to get started. DavidB
did a great job on that. Whenever I need to figure out how to do maven
trickery I usually just download the source to the closest plugin I can
think of. I'm not sure anyone is doing maven plugins in pure-scala, which
might be a downside for the lift framework.
Let me take a shot and see what's required to do a pure-scala maven
plugin. If I'm quick, it might be out soon.
On Thu, Nov 27, 2008 at 12:09 PM, Jorge Ortiz [EMAIL PROTECTED]wrote:
Yeah, I'd love to make this a Maven build plugin. When it comes to Maven
I'm a total dunce though, but I'll look into it.
Any pointers on where to get started?
On Thu, Nov 27, 2008 at 3:59 AM, Josh Suereth [EMAIL PROTECTED]
wrote:
Hey, neat idea! That will definitely help me avoid my own dumb
errors.
I'm just throwing this out there, but would it make sense to try to
make this a Maven build plugin in the future? That way you could control
where it runs in the lifecycle if you wanted to.
-Josh
On Wed, Nov 26, 2008 at 8:07 PM, Jorge Ortiz [EMAIL PROTECTED]wrote:
Oops, it just test *.htm and *.xhtml files as well. Updated code
below.
--j
/**
* Tests to make sure the project's XML files are well-formed.
*
* Finds every *.html and *.xml file in src/main/webapp (and its
* subdirectories) and tests to make sure they are well-formed.
*/
def testXml() = {
var failed: List[java.io.File] = Nil
def handled(file: String) =
file.endsWith(.html) || file.endsWith(.xml) ||
file.endsWith(.htm) || file.endsWith(.xhtml)
def wellFormed(file: java.io.File) {
if (file.isDirectory)
for (f - file.listFiles) wellFormed(f)
if (file.isFile handled(file.getName)) {
try {
scala.xml.XML.loadFile(file)
} catch {
case e: org.xml.sax.SAXParseException = failed = file ::
failed
}
}
}
wellFormed(new java.io.File(src/main/webapp))
val numFails = failed.size
if (numFails 0) {
val fileStr = if (numFails == 1) file else files
val msg = Malformed XML in + numFails + + fileStr + :
+ failed.mkString(, )
println(msg)
fail(msg)
}
}
On Wed, Nov 26, 2008 at 4:58 PM, Jorge Ortiz [EMAIL PROTECTED]wrote:
Folks,
One of the concerns raised at the Lift Workshop on Saturday was that
ill-formed XML files in your templates will fail at run time instead of
compile time, often with cryptic errors.
To correct for this, I've added a simple test to lift-archetype-basic
and lift-archetype-blank that will test all *.html and *.xml files in
your
src/main/webapp directory (and its subdirectories) to make sure they
can all
be loaded by Scala's XML parser. If they can't be loaded the test will
fail
and notify you which files couldn't be loaded and why.
These tests run during Maven's 'test' phase. This phase is required
before the 'package', 'install', or 'deploy' phases can run.
Unfortunately,
the 'jetty:run' phase only requires 'test-compile', not 'test'. If you
want
the test to run before starting Jetty, you'll have to specify it
manually:
'mvn test jetty:run' (or 'mvn install jetty:run', etc).
The test is available on any new projects created with Lift's
archetypes. To add the test to your own project, the code is included
below.
It's a simple JUnit test. If you used a previous version of the
archetypes
to start your project, you can throw it into AppTest.scala
Enjoy,
--j
/**
* Tests to make sure the project's XML files are well-formed.
*
* Finds every *.html and *.xml file in src/main/webapp (and its
* subdirectories) and tests to make sure they are well-formed.
*/
[Lift] Re: Using TemplatePf for JPA powered templates
Hey Derek,
I've been playing around with this nested set stuff today - it's
pretty cool. I nearly have an app working that uses the db for page
content and maps the urls out however you want, it's pretty neat.
I have a slight HQL problem with subquery's but I'll post that 2mro :-)
Thanks for all your help
Tim
Sent from my iPhone
On 30 Nov 2008, at 23:37, Derek Chen-Becker [EMAIL PROTECTED]
wrote:
IIRC, JPA has support for batch updates, but I'm not 100% positive
on that. I'll have more time tomorrow to look at this if you'd still
like to discuss it.
Derek
On Sun, Nov 30, 2008 at 12:32 PM, Tim Perrett [EMAIL PROTECTED]
wrote:
Derek,
Those links are *extremely* good - thank you! I've not really done
anything with tree structures before and they are really, really
usefull.
One thing however, it appears the optimal way of doing the insert
queries would be with stored procedures, however that im not down
with, and ideally, i want to keep database vendor independent (part of
the point of using JPA) so ideally i want to suck that up into the
application logic. For instance:
--START
SELECT @myRight := rgt FROM nested_category WHERE name =
'TELEVISIONS';
UPDATE nested_category SET rgt = rgt + 2 WHERE rgt @myRight;
UPDATE nested_category SET lft = lft + 2 WHERE lft @myRight;
INSERT INTO nested_category(name, lft, rgt) VALUES('GAME CONSOLES',
@myRight + 1, @myRight + 2);
--END
This makes use of variables, and i could of course do this via 3
separate queries in JPA, but i wondered if there was a neater way to
construct this type of thing with JPA?
Any advice you guys have is most welcome
Cheers
Tim
On Nov 30, 2:27 pm, Derek Chen-Becker [EMAIL PROTECTED] wrote:
If you're heavily skewed towards reads and not writes (as it seems
in the
case of a CMS), you might want to look at Celko nested sets:
http://www.intelligententerprise.com/001020/celko.jhtml
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
A little more work on updates than an adjacency model, but a lot
more
efficient.
Derek
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: a plea for documentation
Which book are you talking about? I didn't know that they were already chapters of a lift book we could read. On Wed, Nov 26, 2008 at 9:15 PM, David Stein [EMAIL PROTECTED] wrote: I started looking at a few chapters a while ago, but they were more outlines at the time. Somehow I missed the chapters which are actually pretty comprehensive, like the one on JPA. Very much looking forward to this! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Using TemplatePf for JPA powered templates
Doing nested sets in your Lift snippet is pretty easy with JPA. I'm
doing it on one of my Lift sites. One thing to remember, however, is to
use a transaction. You don't want to do half the update to the tree and
then have another use start an update before you've finished yours (or
have half of it fail). Once it gets messed up it's a disaster.
Nested tables are good when you have lots of lookups, particularly
pulling ancestors or descendants, but not too many updates. Inserts are
not too bad, but if you have to move whole subtrees, that's a pain.
I'm using one for, among other things, a forum, so messages once posted
never get moved. Nested sets work great for that.
But, honestly, it is astonishing to me that Java, Scala, and especially
JPA/Hibernate apparently have no built in features for creating,
manipulating, and persisting trees (and networks are even less
supported). These problems were largely solved long ago. Why aren't they
built in?
Rails has a cool set of plugins -- acts_as_list, acts_as_tree, and
acts_as_nested_set -- that make it drop-dead simple to implement trees.
I was thinking that it would be cool if Lift had something similar but
maybe as a trait? So my object extends ActsAsNestedSet?
I tried to do this in Hibernate, but it would require the object to
query for other similar objects. For example, if I had a Node object
that I was persisting, I'd like to do
class Node extends ActsAsNestedSet
And then define methods such as moveToChildOf(node), moveToFirst,
moveBack, moveForth, moveToLast, etc. But it appears that you need an
EntityManager to run a query, and there doesn't seem to be a way to go
backwards from the Node to the EntityManager (probably because, if I
understand it correctly, there will only be one copy of a given Node in
memory but there may be multiple EntityManagers?).
So I put the code in the snippet.
If you come up with any clever solutions, I'd love to hear them.
Chas.
Tim Perrett wrote:
Hey Derek,
I've been playing around with this nested set stuff today - it's pretty
cool. I nearly have an app working that uses the db for page content and
maps the urls out however you want, it's pretty neat.
I have a slight HQL problem with subquery's but I'll post that 2mro :-)
Thanks for all your help
Tim
Sent from my iPhone
On 30 Nov 2008, at 23:37, Derek Chen-Becker [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
IIRC, JPA has support for batch updates, but I'm not 100% positive on
that. I'll have more time tomorrow to look at this if you'd still like
to discuss it.
Derek
On Sun, Nov 30, 2008 at 12:32 PM, Tim Perrett
mailto:[EMAIL PROTECTED][EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Derek,
Those links are *extremely* good - thank you! I've not really done
anything with tree structures before and they are really, really
usefull.
One thing however, it appears the optimal way of doing the insert
queries would be with stored procedures, however that im not down
with, and ideally, i want to keep database vendor independent (part of
the point of using JPA) so ideally i want to suck that up into the
application logic. For instance:
--START
SELECT @myRight := rgt FROM nested_category WHERE name =
'TELEVISIONS';
UPDATE nested_category SET rgt = rgt + 2 WHERE rgt @myRight;
UPDATE nested_category SET lft = lft + 2 WHERE lft @myRight;
INSERT INTO nested_category(name, lft, rgt) VALUES('GAME CONSOLES',
@myRight + 1, @myRight + 2);
--END
This makes use of variables, and i could of course do this via 3
separate queries in JPA, but i wondered if there was a neater way to
construct this type of thing with JPA?
Any advice you guys have is most welcome
Cheers
Tim
On Nov 30, 2:27 pm, Derek Chen-Becker [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
If you're heavily skewed towards reads and not writes (as it
seems in the
case of a CMS), you might want to look at Celko nested sets:
http://www.intelligententerprise.com/001020/celko.jhtmlhttp://www.intelligententerprise.com/001020/celko.jhtml
http://dev.mysql.com/tech-resources/articles/hierarchical-data.htmlhttp://dev.mysql.com/tech-resources/articles/hierarchical-data.html
A little more work on updates than an adjacency model, but a lot
more
efficient.
Derek
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] JPA find or create new
Is there a simple way in JPA/Lift to query to retrieve a single object from the database, assign it to a val if found, or create a new object of that type and assign it instead of there is no such object in the database? Sort of a... val user: User = Model.createNamedQuery( findUserByUsername, username - hal ).findOr(new User()) or something like that? That would be very useful. Thanks, Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Using TemplatePf for JPA powered templates
On Mon, Dec 1, 2008 at 5:42 AM, Charles F. Munat [EMAIL PROTECTED] wrote:
Doing nested sets in your Lift snippet is pretty easy with JPA. I'm
doing it on one of my Lift sites. One thing to remember, however, is to
use a transaction. You don't want to do half the update to the tree and
then have another use start an update before you've finished yours (or
have half of it fail). Once it gets messed up it's a disaster.
Nested tables are good when you have lots of lookups, particularly
pulling ancestors or descendants, but not too many updates. Inserts are
not too bad, but if you have to move whole subtrees, that's a pain.
I'm using one for, among other things, a forum, so messages once posted
never get moved. Nested sets work great for that.
But, honestly, it is astonishing to me that Java, Scala, and especially
JPA/Hibernate apparently have no built in features for creating,
manipulating, and persisting trees (and networks are even less
supported). These problems were largely solved long ago. Why aren't they
built in?
Charles, I hate to say this, but Hibernate is Open Source, so you can add
the support for it. :)
Rails has a cool set of plugins -- acts_as_list, acts_as_tree, and
acts_as_nested_set -- that make it drop-dead simple to implement trees.
I was thinking that it would be cool if Lift had something similar but
maybe as a trait? So my object extends ActsAsNestedSet?
I tried to do this in Hibernate, but it would require the object to
query for other similar objects. For example, if I had a Node object
that I was persisting, I'd like to do
class Node extends ActsAsNestedSet
And then define methods such as moveToChildOf(node), moveToFirst,
moveBack, moveForth, moveToLast, etc. But it appears that you need an
EntityManager to run a query, and there doesn't seem to be a way to go
backwards from the Node to the EntityManager (probably because, if I
understand it correctly, there will only be one copy of a given Node in
memory but there may be multiple EntityManagers?).
So I put the code in the snippet.
If you come up with any clever solutions, I'd love to hear them.
Chas.
Tim Perrett wrote:
Hey Derek,
I've been playing around with this nested set stuff today - it's pretty
cool. I nearly have an app working that uses the db for page content and
maps the urls out however you want, it's pretty neat.
I have a slight HQL problem with subquery's but I'll post that 2mro :-)
Thanks for all your help
Tim
Sent from my iPhone
On 30 Nov 2008, at 23:37, Derek Chen-Becker [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
IIRC, JPA has support for batch updates, but I'm not 100% positive on
that. I'll have more time tomorrow to look at this if you'd still like
to discuss it.
Derek
On Sun, Nov 30, 2008 at 12:32 PM, Tim Perrett
mailto:[EMAIL PROTECTED][EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Derek,
Those links are *extremely* good - thank you! I've not really done
anything with tree structures before and they are really, really
usefull.
One thing however, it appears the optimal way of doing the insert
queries would be with stored procedures, however that im not down
with, and ideally, i want to keep database vendor independent (part
of
the point of using JPA) so ideally i want to suck that up into the
application logic. For instance:
--START
SELECT @myRight := rgt FROM nested_category WHERE name =
'TELEVISIONS';
UPDATE nested_category SET rgt = rgt + 2 WHERE rgt @myRight;
UPDATE nested_category SET lft = lft + 2 WHERE lft @myRight;
INSERT INTO nested_category(name, lft, rgt) VALUES('GAME CONSOLES',
@myRight + 1, @myRight + 2);
--END
This makes use of variables, and i could of course do this via 3
separate queries in JPA, but i wondered if there was a neater way to
construct this type of thing with JPA?
Any advice you guys have is most welcome
Cheers
Tim
On Nov 30, 2:27 pm, Derek Chen-Becker [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
If you're heavily skewed towards reads and not writes (as it
seems in the
case of a CMS), you might want to look at Celko nested sets:
http://www.intelligententerprise.com/001020/celko.jhtml
http://www.intelligententerprise.com/001020/celko.jhtml
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
A little more work on updates than an adjacency model, but a lot
more
efficient.
Derek
--
Viktor Klang
Senior Systems Analyst
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to
[Lift] Re: JPA find or create new
On Mon, Dec 1, 2008 at 7:12 AM, Charles F. Munat [EMAIL PROTECTED] wrote: Is there a simple way in JPA/Lift to query to retrieve a single object from the database, assign it to a val if found, or create a new object of that type and assign it instead of there is no such object in the database? Sort of a... val user: User = Model.createNamedQuery( findUserByUsername, username - hal ).findOr(new User()) (Can ! (yourQuery.uniqueResult)).openOr(new User()) Should work? or something like that? That would be very useful. Thanks, Chas. -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
