In Derek's defense, it's not how objects in classes work but how Lift
RequestVars work. Scala objects in classes aren't global singletons, just
per-class-instance singletons. But a Lift ReuqestVar object in a class is
pretty much a global singleton (unless you do some hacking like Derek did).
--j
On Tue, Jun 16, 2009 at 11:14 PM, Derek Chen-Becker
<dchenbec...@gmail.com>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> 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> 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> 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>
>>>>
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jean-Luc Canela
>>>> 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
-~----------~----~----~----~------~----~------~--~---
