[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Derek Chen-Becker]

No one need fear. Greg is a benevolent evil genius ;) Seriously, it's
threads like this that make me realize just how many freakin' brilliant
people are on list.

Derek

2009/6/18 Oliver Lambert 

> Hi Greg,
> Thank you, I enjoyed reading that. Perhaps the Greedy Empire, should
> indeed, be worried.
>
> cheers
> Oliver
>
>
> 2009/6/18 Meredith Gregory 
>
>> Oliver,
>>
>> You wrote:
>>
>> we would have taken over Google by now.
>>>
>>
>> My not-so-secret plan for taking over Google is contained in the deck i
>> posted in response to 
>> Viktor.
>> Part of the reason i was excited that Jonas took on to make the JTA wrapper
>> monadic is that it composes perfectly with the ideas explained in the deck.
>> These ideas dovetail perfectly with the DSL stuff i've been working on.
>>
>> My feeling is that we are at a point where things could really start to
>> happen. The ideas are 'in the air' so to speak.
>>
>> Best wishes,
>>
>> --greg
>>
>> 2009/6/17 Oliver Lambert 
>>
>>
>>>
>>> 2009/6/18 Meredith Gregory 
>>>
 Oliver,

 The short answer is no. The longer answer is

- i worked this all out on my own; so, you guys -- who can program
lift on top of scala on top of JVM and are therefore about 20X smarter 
 than
i am -- can too.

 I think if we were all 20X (or 2X) smarter than you, we would have taken
>>> over Google by now.
>>>

-
- And also, help is always available, if there is something specific
you don't understand, let me know and i will do my best to convey it to 
 you.

 As suggested by another kind person, I may have to start by going back
>>> to (an American?) school.
>>>
>>> Heres a question, why should I care about Monad's when they are already
>>> in OO, just not called Monads?
>>>
>>>

-

 Best wishes,

 --greg

 P.S. Here is a version of the paragraph with links to useful bits of
 lore from the literature.

 For myself, i was unhappy with the notion of name. The 
 π-calculiand lambda
 calculi  suffer a
 dependence on a notion of name. Both families of calculi require at least 
 countably
 infinitely  many 
 names,
 and a notion of equality on names. If names have no internal structure then
 these theories *cannot be 
 effective
 *. The reasons is that the notion of equality must then be realized as
 an infinitary table which cannot fit in any computer we have access to.
 Therefore, in effective theories, names must have internal structure. Since
 they have internal structure and are at least countably infinite, one is in
 danger of undermining the foundational character of these proposals for
 computing. Therefore, the only possible solution is that the notion of
 structured name must come from the notion of program proposed by the model.
 This argument is airtight. If you want a foundational model of computing
 with nominal structure, the nominal structure must derive from the notion 
 of
 computation being put forward, i.e. it must *reflect* the notion of
 computation.
 This gives rise to all kinds of new an beautiful phenomena. One measure of
 your way into compositional thinking is whether this is happening. Is your
 approach to compositional thinking beginning to yield whole new aspects of
 computing, and new 'wholes' of computation, new forms of organization.


 2009/6/16 Oliver Lambert 


>
> 2009/6/17 Meredith Gregory 
>
> Jeremy,
>>
>> Most excellent question award to you, sir!
>>
>> How to bootstrap thinking compositionally... this is what i did
>>
>>- learn some compositional idioms by heart
>>   - do you know the shape of the paradoxical combinator by heart
>>   - do you know the data making up a monad
>>   - do you know the data making up a distributive law between
>>   monads
>>   - use them in real world applications and see where they fail
>>   - when is calculating the least/greatest fixpoint of a
>>   recursive spec for a problem the suboptimal solution
>>   - when is a monad not the answer
>>   - when is an indexed form of composition inadequate
>>   - improve them
>>   - is it a situational improvement or
>>   - a fundamental improvement
>>   - see where the very programming model itself fails
>>   - is functional composition the only sort of comp

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Oliver Lambert]

Hi Greg,
Thank you, I enjoyed reading that. Perhaps the Greedy Empire, should indeed,
be worried.

cheers
Oliver

2009/6/18 Meredith Gregory 

> Oliver,
>
> You wrote:
>
> we would have taken over Google by now.
>>
>
> My not-so-secret plan for taking over Google is contained in the deck i
> posted in response to 
> Viktor.
> Part of the reason i was excited that Jonas took on to make the JTA wrapper
> monadic is that it composes perfectly with the ideas explained in the deck.
> These ideas dovetail perfectly with the DSL stuff i've been working on.
>
> My feeling is that we are at a point where things could really start to
> happen. The ideas are 'in the air' so to speak.
>
> Best wishes,
>
> --greg
>
> 2009/6/17 Oliver Lambert 
>
>
>>
>> 2009/6/18 Meredith Gregory 
>>
>>> Oliver,
>>>
>>> The short answer is no. The longer answer is
>>>
>>>- i worked this all out on my own; so, you guys -- who can program
>>>lift on top of scala on top of JVM and are therefore about 20X smarter 
>>> than
>>>i am -- can too.
>>>
>>> I think if we were all 20X (or 2X) smarter than you, we would have taken
>> over Google by now.
>>
>>>
>>>-
>>>- And also, help is always available, if there is something specific
>>>you don't understand, let me know and i will do my best to convey it to 
>>> you.
>>>
>>> As suggested by another kind person, I may have to start by going back to
>> (an American?) school.
>>
>> Heres a question, why should I care about Monad's when they are already in
>> OO, just not called Monads?
>>
>>
>>>
>>>-
>>>
>>> Best wishes,
>>>
>>> --greg
>>>
>>> P.S. Here is a version of the paragraph with links to useful bits of lore
>>> from the literature.
>>>
>>> For myself, i was unhappy with the notion of name. The 
>>> π-calculiand lambda
>>> calculi  suffer a
>>> dependence on a notion of name. Both families of calculi require at least 
>>> countably
>>> infinitely  many 
>>> names,
>>> and a notion of equality on names. If names have no internal structure then
>>> these theories *cannot be 
>>> effective
>>> *. The reasons is that the notion of equality must then be realized as
>>> an infinitary table which cannot fit in any computer we have access to.
>>> Therefore, in effective theories, names must have internal structure. Since
>>> they have internal structure and are at least countably infinite, one is in
>>> danger of undermining the foundational character of these proposals for
>>> computing. Therefore, the only possible solution is that the notion of
>>> structured name must come from the notion of program proposed by the model.
>>> This argument is airtight. If you want a foundational model of computing
>>> with nominal structure, the nominal structure must derive from the notion of
>>> computation being put forward, i.e. it must *reflect* the notion of
>>> computation.
>>> This gives rise to all kinds of new an beautiful phenomena. One measure of
>>> your way into compositional thinking is whether this is happening. Is your
>>> approach to compositional thinking beginning to yield whole new aspects of
>>> computing, and new 'wholes' of computation, new forms of organization.
>>>
>>>
>>> 2009/6/16 Oliver Lambert 
>>>
>>>

 2009/6/17 Meredith Gregory 

 Jeremy,
>
> Most excellent question award to you, sir!
>
> How to bootstrap thinking compositionally... this is what i did
>
>- learn some compositional idioms by heart
>   - do you know the shape of the paradoxical combinator by heart
>   - do you know the data making up a monad
>   - do you know the data making up a distributive law between
>   monads
>   - use them in real world applications and see where they fail
>   - when is calculating the least/greatest fixpoint of a recursive
>   spec for a problem the suboptimal solution
>   - when is a monad not the answer
>   - when is an indexed form of composition inadequate
>   - improve them
>   - is it a situational improvement or
>   - a fundamental improvement
>   - see where the very programming model itself fails
>   - is functional composition the only sort of composition
>   - how is parallel composition like functional composition
>   - is parallel composition easily represented in categorical
>   composition
>   - improve it
>   - what is the view of the world in your notion of composition
>   - play with new programming models
>   - do

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Meredith Gregory]

Oliver,

You wrote:

we would have taken over Google by now.
>

My not-so-secret plan for taking over Google is contained in the deck i
posted in response to
Viktor.
Part of the reason i was excited that Jonas took on to make the JTA wrapper
monadic is that it composes perfectly with the ideas explained in the deck.
These ideas dovetail perfectly with the DSL stuff i've been working on.

My feeling is that we are at a point where things could really start to
happen. The ideas are 'in the air' so to speak.

Best wishes,

--greg

2009/6/17 Oliver Lambert 

>
>
> 2009/6/18 Meredith Gregory 
>
>> Oliver,
>>
>> The short answer is no. The longer answer is
>>
>>- i worked this all out on my own; so, you guys -- who can program
>>lift on top of scala on top of JVM and are therefore about 20X smarter 
>> than
>>i am -- can too.
>>
>> I think if we were all 20X (or 2X) smarter than you, we would have taken
> over Google by now.
>
>>
>>-
>>- And also, help is always available, if there is something specific
>>you don't understand, let me know and i will do my best to convey it to 
>> you.
>>
>> As suggested by another kind person, I may have to start by going back to
> (an American?) school.
>
> Heres a question, why should I care about Monad's when they are already in
> OO, just not called Monads?
>
>
>>
>>-
>>
>> Best wishes,
>>
>> --greg
>>
>> P.S. Here is a version of the paragraph with links to useful bits of lore
>> from the literature.
>>
>> For myself, i was unhappy with the notion of name. The 
>> π-calculiand lambda
>> calculi  suffer a
>> dependence on a notion of name. Both families of calculi require at least 
>> countably
>> infinitely  many 
>> names,
>> and a notion of equality on names. If names have no internal structure then
>> these theories *cannot be 
>> effective
>> *. The reasons is that the notion of equality must then be realized as an
>> infinitary table which cannot fit in any computer we have access to.
>> Therefore, in effective theories, names must have internal structure. Since
>> they have internal structure and are at least countably infinite, one is in
>> danger of undermining the foundational character of these proposals for
>> computing. Therefore, the only possible solution is that the notion of
>> structured name must come from the notion of program proposed by the model.
>> This argument is airtight. If you want a foundational model of computing
>> with nominal structure, the nominal structure must derive from the notion of
>> computation being put forward, i.e. it must *reflect* the notion of
>> computation.
>> This gives rise to all kinds of new an beautiful phenomena. One measure of
>> your way into compositional thinking is whether this is happening. Is your
>> approach to compositional thinking beginning to yield whole new aspects of
>> computing, and new 'wholes' of computation, new forms of organization.
>>
>>
>> 2009/6/16 Oliver Lambert 
>>
>>
>>>
>>> 2009/6/17 Meredith Gregory 
>>>
>>> Jeremy,

 Most excellent question award to you, sir!

 How to bootstrap thinking compositionally... this is what i did

- learn some compositional idioms by heart
   - do you know the shape of the paradoxical combinator by heart
   - do you know the data making up a monad
   - do you know the data making up a distributive law between
   monads
   - use them in real world applications and see where they fail
   - when is calculating the least/greatest fixpoint of a recursive
   spec for a problem the suboptimal solution
   - when is a monad not the answer
   - when is an indexed form of composition inadequate
   - improve them
   - is it a situational improvement or
   - a fundamental improvement
   - see where the very programming model itself fails
   - is functional composition the only sort of composition
   - how is parallel composition like functional composition
   - is parallel composition easily represented in categorical
   composition
   - improve it
   - what is the view of the world in your notion of composition
   - play with new programming models
   - does your new notion of composition give rise to a whole
   generation of different models
   - invent new idioms in these models
   - what are the things these models naturally express
   - and teach them to someone who wishes to bootstrap thinking

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Viktor Klang]

I just want to say that it's educating and awesome (in the true sense of the
word) to have you on this list, enriching us with alot of good ideas,
theories and concepts.

2009/6/18 Meredith Gregory 

> Viktor,
>
> My co-routine yields back to yours!
>
> Hey, it's like Garrison Keillor's Tales from Lake 
> Wobegon:
> where *all* of the children are above average. If you think about it, that
> just keeps *lift*ing the children higher and higher and higher...
>
> Speaking of which, i think David's goat rodeo ideas fit pretty well with
> some ideas i've been working on regarding a uniform approach to data. This
> takes the whole LINQ idea up a couple of notches. To see what i mean, take a
> look at the slides for a recent talk i 
> gave.
> Comments (peanuts, rotten tomatoes...) would be most welcome.
>
> Best wishes,
>
> --greg
>
> P.S. Oliver's sincere question compelled me to respond with my own best
> understanding of the topic.
>
> 2009/6/18 Viktor Klang 
>
>> I yield to your superiority.
>> Seriously.
>>
>>
>> 2009/6/18 Meredith Gregory 
>>
>>> Oliver,
>>>
>>> Objects and monads are really not the same. At it's heart the concept of
>>> monad is an appropriately parametric notion of composition. If you have any
>>> experience with abstract algebra, you might recognize that the notion of
>>> a group  is an
>>> appropriately parametric notion of symmetry. Groups give an exceptionally
>>> well abstracted account of symmetry. Monads give an exceptionally well
>>> abstracted notion of composition. This is a lot easier to see in the
>>> Category Theoretic presentation.
>>>
>>> A monad  is
>>> presented by three pieces of data:
>>>
>>>- An endofunctor  M : C -> C
>>>(intuitively, think of M as a parametric type constructor and C as the
>>>universe of types and maps)
>>>- A natural 
>>> transformationunit: Id 
>>> -> M -- this is a higher-order critter: it takes maps to maps; but
>>>i'll give you a metaphor in just a moment.
>>>- A natural transformation mult: M^2 -> M
>>>
>>> One picture you can have in your mind is M is a kind of "box" factory.
>>> Then unit says how you can put things into a box, and mult says how you can
>>> flatten nested boxes into an ordinary box (this is the origins of flatMap in
>>> Scala's presentation). Another way of understanding this is that M is a kind
>>> of higher-order compositor, i.e. a way of combining things just like
>>> multiplication, as in a*b, is a way of combining things. Then the unit is
>>> the analog of having a unit for your multiplication and mult is the analog
>>> of an associativity law ( a*(b*c) = (a*b)*c ). These line up with the box
>>> analogy more easily if you write things with prefix notation instead of
>>> infix notation.
>>>
>>>- Let's write {*| a, b |*} instead of a*b. The reason we adopt this
>>>more verbose notation is that we can note the different kind of boxes 
>>> with
>>>the 'color' of the braces. M-colored braces, {M| a, b |M}, are associated
>>>with an M-box.
>>>- Then unit( a ) = {M| a |M}, it puts a in an M-box. This has an
>>>alternate presentation of the form {M| |M}.{M| a |M} = {M| a |M}. i 
>>> mention
>>>it to point out the analogy with the binary operation _*_, but it muddies
>>>the water a little with begging the question about the _._. So, i will 
>>> just
>>>leave it -- without explanation -- for you to explore.
>>>- And mult( {M| {M| a11, ..., a1J |M} ... {M| aI1, ... aIJ' |M} |M} )
>>>= {M| a11, ..., aIJ' |M}. It tells you how to canonically flatten 
>>> M-boxes.
>>>This functions as an association because if boxes canonically flatten, 
>>> then
>>>{M| a, {M| b, c |M} |M} = {M| a, b, c |M} = {M| {M| a, b |M}, c |M}.
>>>
>>>
>>> The apparent lexical connection between this way of thinking about things
>>> and XML *is not accidental*. Monads can be viewed as colored braces, aka
>>> matched tags. Monads are a semantical creature that presents syntactically
>>> like XML.
>>>
>>> This way of thinking about things is really different from objects. To be
>>> sure, there are notions of objects that are universal and so can be made to
>>> fit or encode just about anything; but, that doesn't mean the encodings are
>>> nice, or scalable or maintainable. You have only to to look at something
>>> like LINQ -- which is really just a presentation of monads -- to see just
>>> how flexible and yet compact the monadic way of structuring composition is.
>>> Specifically, both set-comprehension notation and SELECT-FROM-WHERE, when
>>> interpreted polymorphically, provide a natural representation of the monad.
>>>
>>>- { pattern | t1 <- generator1, ..., tn <- gene

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Meredith Gregory]

Viktor,

My co-routine yields back to yours!

Hey, it's like Garrison Keillor's Tales from Lake
Wobegon:
where *all* of the children are above average. If you think about it, that
just keeps *lift*ing the children higher and higher and higher...

Speaking of which, i think David's goat rodeo ideas fit pretty well with
some ideas i've been working on regarding a uniform approach to data. This
takes the whole LINQ idea up a couple of notches. To see what i mean, take a
look at the slides for a recent talk i
gave.
Comments (peanuts, rotten tomatoes...) would be most welcome.

Best wishes,

--greg

P.S. Oliver's sincere question compelled me to respond with my own best
understanding of the topic.

2009/6/18 Viktor Klang 

> I yield to your superiority.
> Seriously.
>
>
> 2009/6/18 Meredith Gregory 
>
>> Oliver,
>>
>> Objects and monads are really not the same. At it's heart the concept of
>> monad is an appropriately parametric notion of composition. If you have any
>> experience with abstract algebra, you might recognize that the notion of
>> a group  is an appropriately
>> parametric notion of symmetry. Groups give an exceptionally well abstracted
>> account of symmetry. Monads give an exceptionally well abstracted notion of
>> composition. This is a lot easier to see in the Category Theoretic
>> presentation.
>>
>> A monad  is
>> presented by three pieces of data:
>>
>>- An endofunctor  M : C -> C
>>(intuitively, think of M as a parametric type constructor and C as the
>>universe of types and maps)
>>- A natural 
>> transformationunit: Id 
>> -> M -- this is a higher-order critter: it takes maps to maps; but
>>i'll give you a metaphor in just a moment.
>>- A natural transformation mult: M^2 -> M
>>
>> One picture you can have in your mind is M is a kind of "box" factory.
>> Then unit says how you can put things into a box, and mult says how you can
>> flatten nested boxes into an ordinary box (this is the origins of flatMap in
>> Scala's presentation). Another way of understanding this is that M is a kind
>> of higher-order compositor, i.e. a way of combining things just like
>> multiplication, as in a*b, is a way of combining things. Then the unit is
>> the analog of having a unit for your multiplication and mult is the analog
>> of an associativity law ( a*(b*c) = (a*b)*c ). These line up with the box
>> analogy more easily if you write things with prefix notation instead of
>> infix notation.
>>
>>- Let's write {*| a, b |*} instead of a*b. The reason we adopt this
>>more verbose notation is that we can note the different kind of boxes with
>>the 'color' of the braces. M-colored braces, {M| a, b |M}, are associated
>>with an M-box.
>>- Then unit( a ) = {M| a |M}, it puts a in an M-box. This has an
>>alternate presentation of the form {M| |M}.{M| a |M} = {M| a |M}. i 
>> mention
>>it to point out the analogy with the binary operation _*_, but it muddies
>>the water a little with begging the question about the _._. So, i will 
>> just
>>leave it -- without explanation -- for you to explore.
>>- And mult( {M| {M| a11, ..., a1J |M} ... {M| aI1, ... aIJ' |M} |M} )
>>= {M| a11, ..., aIJ' |M}. It tells you how to canonically flatten M-boxes.
>>This functions as an association because if boxes canonically flatten, 
>> then
>>{M| a, {M| b, c |M} |M} = {M| a, b, c |M} = {M| {M| a, b |M}, c |M}.
>>
>>
>> The apparent lexical connection between this way of thinking about things
>> and XML *is not accidental*. Monads can be viewed as colored braces, aka
>> matched tags. Monads are a semantical creature that presents syntactically
>> like XML.
>>
>> This way of thinking about things is really different from objects. To be
>> sure, there are notions of objects that are universal and so can be made to
>> fit or encode just about anything; but, that doesn't mean the encodings are
>> nice, or scalable or maintainable. You have only to to look at something
>> like LINQ -- which is really just a presentation of monads -- to see just
>> how flexible and yet compact the monadic way of structuring composition is.
>> Specifically, both set-comprehension notation and SELECT-FROM-WHERE, when
>> interpreted polymorphically, provide a natural representation of the monad.
>>
>>- { pattern | t1 <- generator1, ..., tn <- generatorN, constraint1,
>>..., constraintK }
>>- SELECT pattern FROM generator WHERE constraint
>>
>> Those to pieces of computational machinery have very simple, and natural
>> mappings to the monad operations. You will win if you work these out for
>> yourself. Phil Wadler has excellent papers to provide cheat sheets. 

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Viktor Klang]

I yield to your superiority.
Seriously.

2009/6/18 Meredith Gregory 

> Oliver,
>
> Objects and monads are really not the same. At it's heart the concept of
> monad is an appropriately parametric notion of composition. If you have any
> experience with abstract algebra, you might recognize that the notion of a
> group  is an appropriately
> parametric notion of symmetry. Groups give an exceptionally well abstracted
> account of symmetry. Monads give an exceptionally well abstracted notion of
> composition. This is a lot easier to see in the Category Theoretic
> presentation.
>
> A monad  is
> presented by three pieces of data:
>
>- An endofunctor  M : C -> C
>(intuitively, think of M as a parametric type constructor and C as the
>universe of types and maps)
>- A natural 
> transformationunit: Id 
> -> M -- this is a higher-order critter: it takes maps to maps; but
>i'll give you a metaphor in just a moment.
>- A natural transformation mult: M^2 -> M
>
> One picture you can have in your mind is M is a kind of "box" factory. Then
> unit says how you can put things into a box, and mult says how you can
> flatten nested boxes into an ordinary box (this is the origins of flatMap in
> Scala's presentation). Another way of understanding this is that M is a kind
> of higher-order compositor, i.e. a way of combining things just like
> multiplication, as in a*b, is a way of combining things. Then the unit is
> the analog of having a unit for your multiplication and mult is the analog
> of an associativity law ( a*(b*c) = (a*b)*c ). These line up with the box
> analogy more easily if you write things with prefix notation instead of
> infix notation.
>
>- Let's write {*| a, b |*} instead of a*b. The reason we adopt this
>more verbose notation is that we can note the different kind of boxes with
>the 'color' of the braces. M-colored braces, {M| a, b |M}, are associated
>with an M-box.
>- Then unit( a ) = {M| a |M}, it puts a in an M-box. This has an
>alternate presentation of the form {M| |M}.{M| a |M} = {M| a |M}. i mention
>it to point out the analogy with the binary operation _*_, but it muddies
>the water a little with begging the question about the _._. So, i will just
>leave it -- without explanation -- for you to explore.
>- And mult( {M| {M| a11, ..., a1J |M} ... {M| aI1, ... aIJ' |M} |M} ) =
>{M| a11, ..., aIJ' |M}. It tells you how to canonically flatten M-boxes.
>This functions as an association because if boxes canonically flatten, then
>{M| a, {M| b, c |M} |M} = {M| a, b, c |M} = {M| {M| a, b |M}, c |M}.
>
>
> The apparent lexical connection between this way of thinking about things
> and XML *is not accidental*. Monads can be viewed as colored braces, aka
> matched tags. Monads are a semantical creature that presents syntactically
> like XML.
>
> This way of thinking about things is really different from objects. To be
> sure, there are notions of objects that are universal and so can be made to
> fit or encode just about anything; but, that doesn't mean the encodings are
> nice, or scalable or maintainable. You have only to to look at something
> like LINQ -- which is really just a presentation of monads -- to see just
> how flexible and yet compact the monadic way of structuring composition is.
> Specifically, both set-comprehension notation and SELECT-FROM-WHERE, when
> interpreted polymorphically, provide a natural representation of the monad.
>
>- { pattern | t1 <- generator1, ..., tn <- generatorN, constraint1,
>..., constraintK }
>- SELECT pattern FROM generator WHERE constraint
>
> Those to pieces of computational machinery have very simple, and natural
> mappings to the monad operations. You will win if you work these out for
> yourself. Phil Wadler has excellent papers to provide cheat sheets. The
> Scala for-comprehension and the corresponding operations of map, flatMap and
> filter are also excellent cheat sheets. But, you get the joy if you work
> this out for yourself.
>
> Best wishes,
>
> --greg
>
> 2009/6/17 Oliver Lambert 
>
>
>>
>> 2009/6/18 Meredith Gregory 
>>
>>> Oliver,
>>>
>>> The short answer is no. The longer answer is
>>>
>>>- i worked this all out on my own; so, you guys -- who can program
>>>lift on top of scala on top of JVM and are therefore about 20X smarter 
>>> than
>>>i am -- can too.
>>>
>>> I think if we were all 20X (or 2X) smarter than you, we would have taken
>> over Google by now.
>>
>>>
>>>- And also, help is always available, if there is something specific
>>>you don't understand, let me know and i will do my best to convey it to 
>>> you.
>>>
>>> As suggested by another kind person, I may have to start by going back to
>> (an American?) school.
>>
>> Heres a question

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Meredith Gregory]

Oliver,

Objects and monads are really not the same. At it's heart the concept of
monad is an appropriately parametric notion of composition. If you have any
experience with abstract algebra, you might recognize that the notion of a
group  is an appropriately
parametric notion of symmetry. Groups give an exceptionally well abstracted
account of symmetry. Monads give an exceptionally well abstracted notion of
composition. This is a lot easier to see in the Category Theoretic
presentation.

A monad  is
presented by three pieces of data:

   - An endofunctor  M : C -> C
   (intuitively, think of M as a parametric type constructor and C as the
   universe of types and maps)
   - A natural 
transformationunit:
Id -> M -- this is a higher-order critter: it takes maps to maps; but
   i'll give you a metaphor in just a moment.
   - A natural transformation mult: M^2 -> M

One picture you can have in your mind is M is a kind of "box" factory. Then
unit says how you can put things into a box, and mult says how you can
flatten nested boxes into an ordinary box (this is the origins of flatMap in
Scala's presentation). Another way of understanding this is that M is a kind
of higher-order compositor, i.e. a way of combining things just like
multiplication, as in a*b, is a way of combining things. Then the unit is
the analog of having a unit for your multiplication and mult is the analog
of an associativity law ( a*(b*c) = (a*b)*c ). These line up with the box
analogy more easily if you write things with prefix notation instead of
infix notation.

   - Let's write {*| a, b |*} instead of a*b. The reason we adopt this more
   verbose notation is that we can note the different kind of boxes with the
   'color' of the braces. M-colored braces, {M| a, b |M}, are associated with
   an M-box.
   - Then unit( a ) = {M| a |M}, it puts a in an M-box. This has an
   alternate presentation of the form {M| |M}.{M| a |M} = {M| a |M}. i mention
   it to point out the analogy with the binary operation _*_, but it muddies
   the water a little with begging the question about the _._. So, i will just
   leave it -- without explanation -- for you to explore.
   - And mult( {M| {M| a11, ..., a1J |M} ... {M| aI1, ... aIJ' |M} |M} ) =
   {M| a11, ..., aIJ' |M}. It tells you how to canonically flatten M-boxes.
   This functions as an association because if boxes canonically flatten, then
   {M| a, {M| b, c |M} |M} = {M| a, b, c |M} = {M| {M| a, b |M}, c |M}.


The apparent lexical connection between this way of thinking about things
and XML *is not accidental*. Monads can be viewed as colored braces, aka
matched tags. Monads are a semantical creature that presents syntactically
like XML.

This way of thinking about things is really different from objects. To be
sure, there are notions of objects that are universal and so can be made to
fit or encode just about anything; but, that doesn't mean the encodings are
nice, or scalable or maintainable. You have only to to look at something
like LINQ -- which is really just a presentation of monads -- to see just
how flexible and yet compact the monadic way of structuring composition is.
Specifically, both set-comprehension notation and SELECT-FROM-WHERE, when
interpreted polymorphically, provide a natural representation of the monad.

   - { pattern | t1 <- generator1, ..., tn <- generatorN, constraint1, ...,
   constraintK }
   - SELECT pattern FROM generator WHERE constraint

Those to pieces of computational machinery have very simple, and natural
mappings to the monad operations. You will win if you work these out for
yourself. Phil Wadler has excellent papers to provide cheat sheets. The
Scala for-comprehension and the corresponding operations of map, flatMap and
filter are also excellent cheat sheets. But, you get the joy if you work
this out for yourself.

Best wishes,

--greg

2009/6/17 Oliver Lambert 

>
>
> 2009/6/18 Meredith Gregory 
>
>> Oliver,
>>
>> The short answer is no. The longer answer is
>>
>>- i worked this all out on my own; so, you guys -- who can program
>>lift on top of scala on top of JVM and are therefore about 20X smarter 
>> than
>>i am -- can too.
>>
>> I think if we were all 20X (or 2X) smarter than you, we would have taken
> over Google by now.
>
>>
>>- And also, help is always available, if there is something specific
>>you don't understand, let me know and i will do my best to convey it to 
>> you.
>>
>> As suggested by another kind person, I may have to start by going back to
> (an American?) school.
>
> Heres a question, why should I care about Monad's when they are already in
> OO, just not called Monads?
>
>
>>
>>-
>>
>> Best wishes,
>>
>> --greg
>>
>> P.S. Here is a version of the paragraph with links to useful bits of lore
>> from the literature.
>

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Oliver Lambert]

2009/6/18 Meredith Gregory 

> Oliver,
>
> The short answer is no. The longer answer is
>
>- i worked this all out on my own; so, you guys -- who can program lift
>on top of scala on top of JVM and are therefore about 20X smarter than i am
>-- can too.
>
> I think if we were all 20X (or 2X) smarter than you, we would have taken
over Google by now.

>
>-
>- And also, help is always available, if there is something specific
>you don't understand, let me know and i will do my best to convey it to 
> you.
>
> As suggested by another kind person, I may have to start by going back to
(an American?) school.

Heres a question, why should I care about Monad's when they are already in
OO, just not called Monads?


>
>-
>
> Best wishes,
>
> --greg
>
> P.S. Here is a version of the paragraph with links to useful bits of lore
> from the literature.
>
> For myself, i was unhappy with the notion of name. The 
> π-calculiand lambda
> calculi  suffer a dependence
> on a notion of name. Both families of calculi require at least countably
> infinitely  many 
> names,
> and a notion of equality on names. If names have no internal structure then
> these theories *cannot be 
> effective
> *. The reasons is that the notion of equality must then be realized as an
> infinitary table which cannot fit in any computer we have access to.
> Therefore, in effective theories, names must have internal structure. Since
> they have internal structure and are at least countably infinite, one is in
> danger of undermining the foundational character of these proposals for
> computing. Therefore, the only possible solution is that the notion of
> structured name must come from the notion of program proposed by the model.
> This argument is airtight. If you want a foundational model of computing
> with nominal structure, the nominal structure must derive from the notion of
> computation being put forward, i.e. it must *reflect* the notion of
> computation.
> This gives rise to all kinds of new an beautiful phenomena. One measure of
> your way into compositional thinking is whether this is happening. Is your
> approach to compositional thinking beginning to yield whole new aspects of
> computing, and new 'wholes' of computation, new forms of organization.
>
>
> 2009/6/16 Oliver Lambert 
>
>
>>
>> 2009/6/17 Meredith Gregory 
>>
>> Jeremy,
>>>
>>> Most excellent question award to you, sir!
>>>
>>> How to bootstrap thinking compositionally... this is what i did
>>>
>>>- learn some compositional idioms by heart
>>>   - do you know the shape of the paradoxical combinator by heart
>>>   - do you know the data making up a monad
>>>   - do you know the data making up a distributive law between monads
>>>   - use them in real world applications and see where they fail
>>>   - when is calculating the least/greatest fixpoint of a recursive
>>>   spec for a problem the suboptimal solution
>>>   - when is a monad not the answer
>>>   - when is an indexed form of composition inadequate
>>>   - improve them
>>>   - is it a situational improvement or
>>>   - a fundamental improvement
>>>   - see where the very programming model itself fails
>>>   - is functional composition the only sort of composition
>>>   - how is parallel composition like functional composition
>>>   - is parallel composition easily represented in categorical
>>>   composition
>>>   - improve it
>>>   - what is the view of the world in your notion of composition
>>>   - play with new programming models
>>>   - does your new notion of composition give rise to a whole
>>>   generation of different models
>>>   - invent new idioms in these models
>>>   - what are the things these models naturally express
>>>   - and teach them to someone who wishes to bootstrap thinking
>>>compositionally
>>>
>>> For myself, i was unhappy with the notion of name. The π-calculi and
>>> lambda calculi suffer a dependence on a notion of name. Both families of
>>> calculi require at least countably infinitely many names, and a notion of
>>> equality on names. If names have no internal structure then these theories
>>> *cannot be effective*.
>>
>>
>> Do we need to do some sort of course to understand this language?
>>
>>
>>> The reasons is that the notion of equality must then be realized as an
>>> infinitary table which cannot fit in any computer we have access to.
>>> Therefore, in effective theories, names must have internal structure. Since
>>> they have internal structure and are at least countably infinite, one is in
>>> danger of unde

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Matt Williams]

> 
> i trust that all understood i was having good fun. 
> 

The only thing I understood is that there are some people out there
vastly more knowledgeable than myself! :D

Brgds,

Matt



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Meredith Gregory]

Tim,

LOL!

Derek,

i'm amazed at all the good work you've done on lift. You're unstoppable!

i trust that all understood i was having good fun.

Best wishes,

--greg

On Wed, Jun 17, 2009 at 2:07 AM, TSP  wrote:

>
> >>  In my own defense ...  failed to realize the problem that would arise
> from defining the EM factory as a singleton
>
> Are you being honest here Derek? Was not the real problem that you
> failed to truly embrace the shape of the paradoxical combinator?
>
>
> >
>


-- 
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
-~--~~~~--~~--~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[David Pollak]

On Wed, Jun 17, 2009 at 12:04 PM, Derek Chen-Becker
wrote:

> Argh, that's what I was trying to say. No more posting after Midnight for
> me :(


Folks,

We are all on the path to doing better development... but it's a journey,
not a destination.  I like Greg's suggestion of thinking compositionally and
have myself been struggling to improve my compositional thinking.  I like
Derek's responsiveness to the user community and improvements to his ways of
thinking.  We are all being agile (in the best sense of the word.)  We are
all being JIT.  Let's continue to improve as coders and improve the Lift
code base and community.

Thanks,

David


>
>
> On Wed, Jun 17, 2009 at 12:29 AM, Jorge Ortiz 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,

 
 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.
 

 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  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 
>>
>>>  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("db

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Meredith Gregory]

Oliver,

The short answer is no. The longer answer is

   - i worked this all out on my own; so, you guys -- who can program lift
   on top of scala on top of JVM and are therefore about 20X smarter than i am
   -- can too.
   - And also, help is always available, if there is something specific you
   don't understand, let me know and i will do my best to convey it to you.

Best wishes,

--greg

P.S. Here is a version of the paragraph with links to useful bits of lore
from the literature.

For myself, i was unhappy with the notion of name. The
π-calculiand lambda
calculi  suffer a dependence
on a notion of name. Both families of calculi require at least countably
infinitely  many
names,
and a notion of equality on names. If names have no internal structure then
these theories *cannot be
effective
*. The reasons is that the notion of equality must then be realized as an
infinitary table which cannot fit in any computer we have access to.
Therefore, in effective theories, names must have internal structure. Since
they have internal structure and are at least countably infinite, one is in
danger of undermining the foundational character of these proposals for
computing. Therefore, the only possible solution is that the notion of
structured name must come from the notion of program proposed by the model.
This argument is airtight. If you want a foundational model of computing
with nominal structure, the nominal structure must derive from the notion of
computation being put forward, i.e. it must *reflect* the notion of
computation.
This gives rise to all kinds of new an beautiful phenomena. One measure of
your way into compositional thinking is whether this is happening. Is your
approach to compositional thinking beginning to yield whole new aspects of
computing, and new 'wholes' of computation, new forms of organization.


2009/6/16 Oliver Lambert 

>
>
> 2009/6/17 Meredith Gregory 
>
> Jeremy,
>>
>> Most excellent question award to you, sir!
>>
>> How to bootstrap thinking compositionally... this is what i did
>>
>>- learn some compositional idioms by heart
>>   - do you know the shape of the paradoxical combinator by heart
>>   - do you know the data making up a monad
>>   - do you know the data making up a distributive law between monads
>>   - use them in real world applications and see where they fail
>>   - when is calculating the least/greatest fixpoint of a recursive
>>   spec for a problem the suboptimal solution
>>   - when is a monad not the answer
>>   - when is an indexed form of composition inadequate
>>   - improve them
>>   - is it a situational improvement or
>>   - a fundamental improvement
>>   - see where the very programming model itself fails
>>   - is functional composition the only sort of composition
>>   - how is parallel composition like functional composition
>>   - is parallel composition easily represented in categorical
>>   composition
>>   - improve it
>>   - what is the view of the world in your notion of composition
>>   - play with new programming models
>>   - does your new notion of composition give rise to a whole
>>   generation of different models
>>   - invent new idioms in these models
>>   - what are the things these models naturally express
>>   - and teach them to someone who wishes to bootstrap thinking
>>compositionally
>>
>> For myself, i was unhappy with the notion of name. The π-calculi and
>> lambda calculi suffer a dependence on a notion of name. Both families of
>> calculi require at least countably infinitely many names, and a notion of
>> equality on names. If names have no internal structure then these theories
>> *cannot be effective*.
>
>
> Do we need to do some sort of course to understand this language?
>
>
>> The reasons is that the notion of equality must then be realized as an
>> infinitary table which cannot fit in any computer we have access to.
>> Therefore, in effective theories, names must have internal structure. Since
>> they have internal structure and are at least countably infinite, one is in
>> danger of undermining the foundational character of these proposals for
>> computing. Therefore, the only possible solution is that the notion of
>> structured name must come from the notion of program proposed by the model.
>> This argument is airtight. If you want a foundational model of computing
>> with nominal structure, the nominal structure must derive from the notion of
>> computation being put forward, i.e. it must *reflect* the notion of
>> computation. This gives rise to all kinds of new 

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Derek Chen-Becker]

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  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  > 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,
>>>
>>> 
>>> 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.
>>> 
>>>
>>> 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  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 
>
>>  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() 
>>

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Matt Williams]

JIT development ;)

In all serious though, its better to have a minimal set of features that
work well and can be refactored effortlessly, than to define an entire
API and have everything need to change in an updated release.

And at the speed this particular fix went in, its hardly hindering
progress!

On Wed, 2009-06-17 at 08:45 -0700, Andrew Scherpbier wrote:
> 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



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Andrew Scherpbier]

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 
> mailto:lgreg.mered...@gmail.com>> wrote:
>
> Derek,
>
> 
> 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.
> 
>
> 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
> 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*  > 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  >
>
> 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
>   

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Eric Bowman]

Oliver Lambert wrote:
> Do we need to do some sort of course to understand this language?
This could help:
http://www.mitadmissions.org/topics/apply/the_freshman_application/index.shtml

:)

-- 
Eric Bowman
Boboco Ltd
ebow...@boboco.ie
http://www.boboco.ie/ebowman/pubkey.pgp
+35318394189/+353872801532


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Jean-Luc]

Hi Derek,

I had issues with the http proxy, so I checked building from source code
(scalajpa + lift-jpa) .
It's perfect, just what I need !

Thank you very much ;-)

Jean-Luc


2009/6/16 Derek Chen-Becker 

> OK, I just checked in code that should allow this to work. Could you please
> test and make sure that it's functioning correctly?
>
> Thanks,
>
> Derek
>
>
> On 6/16/09, Derek Chen-Becker  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  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 
>>>
  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
>>>
>>>
>>>
>>
>
> >
>


-- 
Jean-Luc Canela
jlcane...@gmail.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
-~--~~~~--~~--~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Viktor Klang]

Read this and join me in having your brains implode:

http://www.mail-archive.com/everything-l...@googlegroups.com/msg05959.html

On Wed, Jun 17, 2009 at 11:07 AM, TSP  wrote:

>
> >>  In my own defense ...  failed to realize the problem that would arise
> from defining the EM factory as a singleton
>
> Are you being honest here Derek? Was not the real problem that you
> failed to truly embrace the shape of the paradoxical combinator?
>
>
> >
>


-- 
Viktor Klang
Scala Loudmouth

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[TSP]

>>  In my own defense ...  failed to realize the problem that would arise from 
>> defining the EM factory as a singleton

Are you being honest here Derek? Was not the real problem that you
failed to truly embrace the shape of the paradoxical combinator?


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Oliver Lambert]

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 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,
>>
>> 
>> 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.
>> 
>>
>> 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  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 

>  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
>>>

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Jorge Ortiz]

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
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,
>>
>> 
>> 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.
>> 
>>
>> 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  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 

>  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 & cha

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Derek Chen-Becker]

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
wrote:

> Derek,
>
> 
> 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.
> 
>
> 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  > 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  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 
>>>
  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 libra

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Oliver Lambert]

2009/6/17 Meredith Gregory 

> Jeremy,
>
> Most excellent question award to you, sir!
>
> How to bootstrap thinking compositionally... this is what i did
>
>- learn some compositional idioms by heart
>   - do you know the shape of the paradoxical combinator by heart
>   - do you know the data making up a monad
>   - do you know the data making up a distributive law between monads
>   - use them in real world applications and see where they fail
>   - when is calculating the least/greatest fixpoint of a recursive
>   spec for a problem the suboptimal solution
>   - when is a monad not the answer
>   - when is an indexed form of composition inadequate
>   - improve them
>   - is it a situational improvement or
>   - a fundamental improvement
>   - see where the very programming model itself fails
>   - is functional composition the only sort of composition
>   - how is parallel composition like functional composition
>   - is parallel composition easily represented in categorical
>   composition
>   - improve it
>   - what is the view of the world in your notion of composition
>   - play with new programming models
>   - does your new notion of composition give rise to a whole
>   generation of different models
>   - invent new idioms in these models
>   - what are the things these models naturally express
>   - and teach them to someone who wishes to bootstrap thinking
>compositionally
>
> For myself, i was unhappy with the notion of name. The π-calculi and lambda
> calculi suffer a dependence on a notion of name. Both families of calculi
> require at least countably infinitely many names, and a notion of equality
> on names. If names have no internal structure then these theories *cannot
> be effective*.


Do we need to do some sort of course to understand this language?


> The reasons is that the notion of equality must then be realized as an
> infinitary table which cannot fit in any computer we have access to.
> Therefore, in effective theories, names must have internal structure. Since
> they have internal structure and are at least countably infinite, one is in
> danger of undermining the foundational character of these proposals for
> computing. Therefore, the only possible solution is that the notion of
> structured name must come from the notion of program proposed by the model.
> This argument is airtight. If you want a foundational model of computing
> with nominal structure, the nominal structure must derive from the notion of
> computation being put forward, i.e. it must *reflect* the notion of
> computation. This gives rise to all kinds of new an beautiful phenomena. One
> measure of your way into compositional thinking is whether this is
> happening. Is your approach to compositional thinking beginning to yield
> whole new aspects of computing, and new 'wholes' of computation, new forms
> of organization.
>
> Best wishes,
>
> --greg
>
> On Tue, Jun 16, 2009 at 7:31 PM, Jeremy Day  wrote:
>
>> Greg,
>>
>> On Tue, Jun 16, 2009 at 6:38 PM, Meredith Gregory <
>> lgreg.mered...@gmail.com> wrote:
>>
>>> It takes some serious training to think compositionally.
>>
>>
>> No doubt it is extremely tough to think compositionally, and it's all too
>> easy to fall back on non-compositional ways of thinking.  In a similar vein
>> it's all too easy to fall into procedural patterns when learning or working
>> with functional programming in a multi-paradigm language.  But what are good
>> ways for programmers to learn to think compositionally and, more
>> importantly, practice?  Do you know of any books or online references that
>> might help make the transition for anyone who is interested?
>>
>> Jeremy
>>
>>
>>
>
>
> --
> 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
-~--~~~~--~~--~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Meredith Gregory]

Jeremy,

Most excellent question award to you, sir!

How to bootstrap thinking compositionally... this is what i did

   - learn some compositional idioms by heart
  - do you know the shape of the paradoxical combinator by heart
  - do you know the data making up a monad
  - do you know the data making up a distributive law between monads
  - use them in real world applications and see where they fail
  - when is calculating the least/greatest fixpoint of a recursive spec
  for a problem the suboptimal solution
  - when is a monad not the answer
  - when is an indexed form of composition inadequate
  - improve them
  - is it a situational improvement or
  - a fundamental improvement
  - see where the very programming model itself fails
  - is functional composition the only sort of composition
  - how is parallel composition like functional composition
  - is parallel composition easily represented in categorical
  composition
  - improve it
  - what is the view of the world in your notion of composition
  - play with new programming models
  - does your new notion of composition give rise to a whole generation
  of different models
  - invent new idioms in these models
  - what are the things these models naturally express
  - and teach them to someone who wishes to bootstrap thinking
   compositionally

For myself, i was unhappy with the notion of name. The π-calculi and lambda
calculi suffer a dependence on a notion of name. Both families of calculi
require at least countably infinitely many names, and a notion of equality
on names. If names have no internal structure then these theories *cannot be
effective*. The reasons is that the notion of equality must then be realized
as an infinitary table which cannot fit in any computer we have access to.
Therefore, in effective theories, names must have internal structure. Since
they have internal structure and are at least countably infinite, one is in
danger of undermining the foundational character of these proposals for
computing. Therefore, the only possible solution is that the notion of
structured name must come from the notion of program proposed by the model.
This argument is airtight. If you want a foundational model of computing
with nominal structure, the nominal structure must derive from the notion of
computation being put forward, i.e. it must *reflect* the notion of
computation. This gives rise to all kinds of new an beautiful phenomena. One
measure of your way into compositional thinking is whether this is
happening. Is your approach to compositional thinking beginning to yield
whole new aspects of computing, and new 'wholes' of computation, new forms
of organization.

Best wishes,

--greg

On Tue, Jun 16, 2009 at 7:31 PM, Jeremy Day  wrote:

> Greg,
>
> On Tue, Jun 16, 2009 at 6:38 PM, Meredith Gregory <
> lgreg.mered...@gmail.com> wrote:
>
>> It takes some serious training to think compositionally.
>
>
> No doubt it is extremely tough to think compositionally, and it's all too
> easy to fall back on non-compositional ways of thinking.  In a similar vein
> it's all too easy to fall into procedural patterns when learning or working
> with functional programming in a multi-paradigm language.  But what are good
> ways for programmers to learn to think compositionally and, more
> importantly, practice?  Do you know of any books or online references that
> might help make the transition for anyone who is interested?
>
> Jeremy
>
> >
>


-- 
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
-~--~~~~--~~--~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Jeremy Day]

Greg,

On Tue, Jun 16, 2009 at 6:38 PM, Meredith Gregory
wrote:

> It takes some serious training to think compositionally.


No doubt it is extremely tough to think compositionally, and it's all too
easy to fall back on non-compositional ways of thinking.  In a similar vein
it's all too easy to fall into procedural patterns when learning or working
with functional programming in a multi-paradigm language.  But what are good
ways for programmers to learn to think compositionally and, more
importantly, practice?  Do you know of any books or online references that
might help make the transition for anyone who is interested?

Jeremy

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Oliver Lambert]

I think you have just volunteered to help refactor this code to make it more
composition friendly :)

On Wed, Jun 17, 2009 at 9:38 AM, Meredith Gregory
wrote:

> Derek,
>
> 
> 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.
> 
>
> 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  > 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  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 
>>>
  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 recei

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Meredith Gregory]

Derek,


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.


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
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  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 
>>
>>>  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
-~--~~~~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Derek Chen-Becker]

OK, I just checked in code that should allow this to work. Could you please
test and make sure that it's functioning correctly?

Thanks,

Derek

On 6/16/09, Derek Chen-Becker  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  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 
>>
>>>  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
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Derek Chen-Becker]

 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  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 
>
>>  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
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Jean-Luc]

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 

> 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

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---