Isn't this just the result of JIT development? Don't need something right now, don't implement it. If you need it later, refactor. I'm probably looking at this too much from a low level grunt developer. I understand that when developing a framework or anything with a public API these are important issues, but that's what bugtrackers are for!
I'm all for composability, but it shouldn't be a religion :-) (<-- please note the smiley!) --Andrew Derek Chen-Becker wrote: > I agree that it's an issue. In my own defense, what I meant was not > that I didn't think people would use more than one DB. I actually have > several apps (not yet converted to Lift) that use 4 or more > persistence units that represent various legacy databases. Rather, I > failed to realize the problem that would arise from defining the EM > factory as a singleton because when I wrote that code I didn't fully > understand how member objects on classes worked. Other than that, I > agree with your post :) > Derek > > On Tue, Jun 16, 2009 at 5:38 PM, Meredith Gregory > <lgreg.mered...@gmail.com <mailto:lgreg.mered...@gmail.com>> wrote: > > Derek, > > <soapbox> > You have just demonstrated a process that i have been talking > about for the last 15 years. People have a blind spot when it > comes to thinking compositionally. They think -- almost to a > person -- about "god's eye view" solutions where there's only one > of some key solution component. They don't think about solutions > that are composed of ... (wait for it)... solutions! It takes some > serious training to think compositionally. Compositional > solutions, however, are the only realistic way to scale. When > solutions are compositional, you can _/de/_compose. The db example > is a case in point. One of the most natural ways to scale data > access is sharding and partitioning -- which requires upfront > machinery to support decomposition of the store. > > Lest you feel bad, note that some of the best scientific minds of > all time have fallen prey to this blind spot. Newtonian physics as > well as Einstein's update to Newton's proposal is a > non-compositional solution. Quantum mechanics also exhibits > compositional failures. This is why physics is failing to find > proposals that link theories of gravitation (essentially large > scale) to quantum mechanical theories of the other forces > (essentially very small scale) -- the physical theories are > non-compositional -- they don't scale! > > One of the real things functional programming has going for it is > that the basic model of computation underlying the means of > structuring and manipulating programs is compositional. That's why > it is important to have a technology like Scala resting atop the > incumbent execution model (JVM) being deployed on web-scale > problems. Compositionality is the only way to tackle applications > at global scale. > </soapbox> > > Thanks for getting the fix to this problem in so quickly. > > Best wishes, > > --greg > > > On Tue, Jun 16, 2009 at 11:53 AM, Derek Chen-Becker > <dchenbec...@gmail.com <mailto:dchenbec...@gmail.com>> wrote: > > Using multiple EMs was not something I had considered when I > wrote this. I think that I can modify the code to provide a > __nameSalt def to differentiate instances. Let me work on it > and I'll have something soon. > > Derek > > > On 6/16/09, *Jean-Luc* <jlcane...@gmail.com > <mailto:jlcane...@gmail.com>> wrote: > > For your information, here is an extract of source code of > RequestVarEM : > > Trait RequestVarEM extends ScalaEntityManager with > ScalaEMFactory { > object emVar extends > RequestVar[EntityManager](openEM()) { ... } > } > > EntityManager is stored in the singleton emVar; so, all db > access of Model objects are made using the singleton emVar. > => trait RequestVarEM allow only one connection to a > database within the same HttpRequest context. > > > Jean-Luc > > 2009/6/15 Jean-Luc <jlcane...@gmail.com > <mailto:jlcane...@gmail.com>> > > Hello, > > I have two databases, db1 (a.k.a. Motorbike) and db2 > (a.k.a. Motorway) defined with RequestVarEM : > - object ModelDb1 extends LocalEMF("db1") with > RequestVarEM // Motorbike database > - object ModelDb2 extends LocalEMF("db2") with > RequestVarEM // Motorway database > > I thought one could access to any databases > independently from any snippet as long as the correct > Model object were used (ModelDb1 or ModelDb2 for > exemple) ; but when I access both databases from the > same page, the second database access issues a "Named > query not found" exception. > > I have two snippets, one to display a list of > "motorbike", another to display a list of "motorway" : > - page1 : > > ModelDb1.createNamedQuery[Motorbike]("Motorbike.findAll).getResultList() > => ok > - page2 > : > ModelDb2.createNamedQuery[Motorway]("Motorway.findAll).getResultList() > => ok > - page3 : calling from page 3 motorbike & motorway > snippets : Named query not found: Motorway.findAll > - page4 : calling from page 4 motorway & motorbike > snippets : Named query not found: Motorbike.findAll > - page3 & changing the query of *Motorway* snippet : > - > > ModelDb2.createNamedQuery[*Motorbike*]("*Motorbike*.findAll).getResultList() > => it's ok and I do NOT have an exception ! > > I joined a sample application, ... > > any idea about this issue ? > (bad use of LocalEMF in the application code ? issue > with LocalEMF or RequestVarEM ?) > > Jean-Luc > > PS : > I don't know if it's related but I have this in the log : > [INFO] Checking for multiple versions of scala > [WARNING] Multiple versions of scala libraries detected! > > > > -- > Jean-Luc Canela > jlcane...@gmail.com <mailto:jlcane...@gmail.com> > > > > > -- > Jean-Luc Canela > jlcane...@gmail.com <mailto:jlcane...@gmail.com> > > > > > > > > > -- > L.G. Meredith > Managing Partner > Biosimilarity LLC > 1219 NW 83rd St > Seattle, WA 98117 > > +1 206.650.3740 > > http://biosimilarity.blogspot.com > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
