Argh, that's what I was trying to say. No more posting after Midnight for me
:(
On Wed, Jun 17, 2009 at 12:29 AM, Jorge Ortiz <jorge.or...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
