You made an assumption and programmed a solution based on the knowledge you
had at the time. Thats fine and there is nothing wrong with it - start with
the simplest solution that fits. If it need to be changed due to changing
requirements, thats fine too. There is a tradeoff in creating a overly
complex solution that fits problems that you think might exist in the future
and simplicity. Also, there is nothing that makes composition an idea that
is only understood and relevant to functional programming as almost seems to
be suggested here.
On Wed, Jun 17, 2009 at 4: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
-~----------~----~----~----~------~----~------~--~---
