[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
I yield to your superiority.
Seriously.
2009/6/18 Meredith Gregory lgreg.mered...@gmail.com
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 http://en.wikipedia.org/wiki/Symmetry_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 http://en.wikipedia.org/wiki/Monad_%28category_theory%29 is
presented by three pieces of data:
- An endofunctor http://en.wikipedia.org/wiki/Functor M : C - C
(intuitively, think of M as a parametric type constructor and C as the
universe of types and maps)
- A natural
transformationhttp://en.wikipedia.org/wiki/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 olambo...@gmail.com
2009/6/18 Meredith Gregory lgreg.mered...@gmail.com
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?
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
Viktor,
My co-routine yields back to yours!
Hey, it's like Garrison Keillor's Tales from Lake
Wobegonhttp://en.wikipedia.org/wiki/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
gavehttp://svn.biosimilarity.com/src/open/talks/MonadicDesignPatternsForTheWeb.pdf.
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 viktor.kl...@gmail.com
I yield to your superiority.
Seriously.
2009/6/18 Meredith Gregory lgreg.mered...@gmail.com
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 http://en.wikipedia.org/wiki/Symmetry_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 http://en.wikipedia.org/wiki/Monad_%28category_theory%29 is
presented by three pieces of data:
- An endofunctor http://en.wikipedia.org/wiki/Functor M : C - C
(intuitively, think of M as a parametric type constructor and C as the
universe of types and maps)
- A natural
transformationhttp://en.wikipedia.org/wiki/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.
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
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 lgreg.mered...@gmail.com
Viktor,
My co-routine yields back to yours!
Hey, it's like Garrison Keillor's Tales from Lake
Wobegonhttp://en.wikipedia.org/wiki/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
gavehttp://svn.biosimilarity.com/src/open/talks/MonadicDesignPatternsForTheWeb.pdf.
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 viktor.kl...@gmail.com
I yield to your superiority.
Seriously.
2009/6/18 Meredith Gregory lgreg.mered...@gmail.com
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 http://en.wikipedia.org/wiki/Symmetry_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 http://en.wikipedia.org/wiki/Monad_%28category_theory%29 is
presented by three pieces of data:
- An endofunctor http://en.wikipedia.org/wiki/Functor M : C - C
(intuitively, think of M as a parametric type constructor and C as the
universe of types and maps)
- A natural
transformationhttp://en.wikipedia.org/wiki/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
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
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 Viktorhttp://svn.biosimilarity.com/src/open/talks/MonadicDesignPatternsForTheWeb.pdf. 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 olambo...@gmail.com 2009/6/18 Meredith Gregory lgreg.mered...@gmail.com 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 π-calculihttp://en.wikipedia.org/wiki/Pi-calculusand lambda calculi http://en.wikipedia.org/wiki/Lambda_calculus suffer a dependence on a notion of name. Both families of calculi require at least countably infinitely http://en.wikipedia.org/wiki/Countable many nameshttp://www.cs.nps.navy.mil/research/languages/statements/gordon.html, and a notion of equality on names. If names have no internal structure then these theories *cannot be effectivehttp://en.wikipedia.org/wiki/Computable_function *. 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 computationhttp://svn.biosimilarity.com/src/open/papers/trunk/concurrency/rho/ex_nihilo_entcs/ex_nihilo_finco.pdf. 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 olambo...@gmail.com 2009/6/17 Meredith Gregory lgreg.mered...@gmail.com 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
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
Hi Greg, Thank you, I enjoyed reading that. Perhaps the Greedy Empire, should indeed, be worried. cheers Oliver 2009/6/18 Meredith Gregory lgreg.mered...@gmail.com 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 Viktorhttp://svn.biosimilarity.com/src/open/talks/MonadicDesignPatternsForTheWeb.pdf. 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 olambo...@gmail.com 2009/6/18 Meredith Gregory lgreg.mered...@gmail.com 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 π-calculihttp://en.wikipedia.org/wiki/Pi-calculusand lambda calculi http://en.wikipedia.org/wiki/Lambda_calculus suffer a dependence on a notion of name. Both families of calculi require at least countably infinitely http://en.wikipedia.org/wiki/Countable many nameshttp://www.cs.nps.navy.mil/research/languages/statements/gordon.html, and a notion of equality on names. If names have no internal structure then these theories *cannot be effectivehttp://en.wikipedia.org/wiki/Computable_function *. 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 computationhttp://svn.biosimilarity.com/src/open/papers/trunk/concurrency/rho/ex_nihilo_entcs/ex_nihilo_finco.pdf. 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 olambo...@gmail.com 2009/6/17 Meredith Gregory lgreg.mered...@gmail.com 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
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 olambo...@gmail.com Hi Greg, Thank you, I enjoyed reading that. Perhaps the Greedy Empire, should indeed, be worried. cheers Oliver 2009/6/18 Meredith Gregory lgreg.mered...@gmail.com 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 Viktorhttp://svn.biosimilarity.com/src/open/talks/MonadicDesignPatternsForTheWeb.pdf. 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 olambo...@gmail.com 2009/6/18 Meredith Gregory lgreg.mered...@gmail.com 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 π-calculihttp://en.wikipedia.org/wiki/Pi-calculusand lambda calculi http://en.wikipedia.org/wiki/Lambda_calculus suffer a dependence on a notion of name. Both families of calculi require at least countably infinitely http://en.wikipedia.org/wiki/Countable many nameshttp://www.cs.nps.navy.mil/research/languages/statements/gordon.html, and a notion of equality on names. If names have no internal structure then these theories *cannot be effectivehttp://en.wikipedia.org/wiki/Computable_function *. 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 computationhttp://svn.biosimilarity.com/src/open/papers/trunk/concurrency/rho/ex_nihilo_entcs/ex_nihilo_finco.pdf. 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 olambo...@gmail.com 2009/6/17 Meredith Gregory lgreg.mered...@gmail.com 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
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
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.comwrote:
Derek,
soapbox
You have just demonstrated a process that i have been talking about for the
last 15 years. People have a blind spot when it comes to thinking
compositionally. They think -- almost to a person -- about god's eye view
solutions where there's only one of some key solution component. They don't
think about solutions that are composed of ... (wait for it)... solutions!
It takes some serious training to think compositionally. Compositional
solutions, however, are the only realistic way to scale. When solutions are
compositional, you can *de*compose. The db example is a case in point. One
of the most natural ways to scale data access is sharding and partitioning
-- which requires upfront machinery to support decomposition of the store.
Lest you feel bad, note that some of the best scientific minds of all time
have fallen prey to this blind spot. Newtonian physics as well as Einstein's
update to Newton's proposal is a non-compositional solution. Quantum
mechanics also exhibits compositional failures. This is why physics is
failing to find proposals that link theories of gravitation (essentially
large scale) to quantum mechanical theories of the other forces (essentially
very small scale) -- the physical theories are non-compositional -- they
don't scale!
One of the real things functional programming has going for it is that the
basic model of computation underlying the means of structuring and
manipulating programs is compositional. That's why it is important to have a
technology like Scala resting atop the incumbent execution model (JVM) being
deployed on web-scale problems. Compositionality is the only way to tackle
applications at global scale.
/soapbox
Thanks for getting the fix to this problem in so quickly.
Best wishes,
--greg
On Tue, Jun 16, 2009 at 11:53 AM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
Using multiple EMs was not something I had considered when I wrote this. I
think that I can modify the code to provide a __nameSalt def to
differentiate instances. Let me work on it and I'll have something soon.
Derek
On 6/16/09, Jean-Luc jlcane...@gmail.com wrote:
For your information, here is an extract of source code of RequestVarEM :
Trait RequestVarEM extends ScalaEntityManager with ScalaEMFactory {
object emVar extends RequestVar[EntityManager](openEM()) { ... }
}
EntityManager is stored in the singleton emVar; so, all db access of
Model objects are made using the singleton emVar.
= trait RequestVarEM allow only one connection to a database within the
same HttpRequest context.
Jean-Luc
2009/6/15 Jean-Luc jlcane...@gmail.com
Hello,
I have two databases, db1 (a.k.a. Motorbike) and db2 (a.k.a. Motorway)
defined with RequestVarEM :
- object ModelDb1 extends LocalEMF(db1) with RequestVarEM //
Motorbike database
- object ModelDb2 extends LocalEMF(db2) with RequestVarEM // Motorway
database
I thought one could access to any databases independently from any
snippet as long as the correct Model object were used (ModelDb1 or ModelDb2
for exemple) ; but when I access both databases from the same page, the
second database access issues a Named query not found exception.
I have two snippets, one to display a list of motorbike, another to
display a list of motorway :
- page1 :
ModelDb1.createNamedQuery[Motorbike](Motorbike.findAll).getResultList() =
ok
- page2
: ModelDb2.createNamedQuery[Motorway](Motorway.findAll).getResultList() =
ok
- page3 : calling from page 3 motorbike motorway snippets : Named
query not found: Motorway.findAll
- page4 : calling from page 4 motorway motorbike snippets : Named
query not found: Motorbike.findAll
- page3 changing the query of *Motorway* snippet :
-
ModelDb2.createNamedQuery[*Motorbike*](*Motorbike*.findAll).getResultList()
= it's ok and I do NOT have an exception !
I joined a sample application, ...
any idea about this issue ?
(bad use of LocalEMF in the application code ? issue with LocalEMF or
RequestVarEM ?)
Jean-Luc
PS :
I don't know if it's related but I have this in the log :
[INFO] Checking for multiple versions of scala
[WARNING] Multiple versions of scala libraries detected!
--
Jean-Luc Canela
jlcane...@gmail.com
--
Jean-Luc Canela
jlcane...@gmail.com
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
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.comwrote:
I agree that it's an issue. In my own defense, what I meant was not that I
didn't think people would use more than one DB. I actually have several apps
(not yet converted to Lift) that use 4 or more persistence units that
represent various legacy databases. Rather, I failed to realize the problem
that would arise from defining the EM factory as a singleton because when I
wrote that code I didn't fully understand how member objects on classes
worked. Other than that, I agree with your post :)
Derek
On Tue, Jun 16, 2009 at 5:38 PM, Meredith Gregory
lgreg.mered...@gmail.com wrote:
Derek,
soapbox
You have just demonstrated a process that i have been talking about for
the last 15 years. People have a blind spot when it comes to thinking
compositionally. They think -- almost to a person -- about god's eye view
solutions where there's only one of some key solution component. They don't
think about solutions that are composed of ... (wait for it)... solutions!
It takes some serious training to think compositionally. Compositional
solutions, however, are the only realistic way to scale. When solutions are
compositional, you can *de*compose. The db example is a case in point.
One of the most natural ways to scale data access is sharding and
partitioning -- which requires upfront machinery to support decomposition of
the store.
Lest you feel bad, note that some of the best scientific minds of all time
have fallen prey to this blind spot. Newtonian physics as well as Einstein's
update to Newton's proposal is a non-compositional solution. Quantum
mechanics also exhibits compositional failures. This is why physics is
failing to find proposals that link theories of gravitation (essentially
large scale) to quantum mechanical theories of the other forces (essentially
very small scale) -- the physical theories are non-compositional -- they
don't scale!
One of the real things functional programming has going for it is that the
basic model of computation underlying the means of structuring and
manipulating programs is compositional. That's why it is important to have a
technology like Scala resting atop the incumbent execution model (JVM) being
deployed on web-scale problems. Compositionality is the only way to tackle
applications at global scale.
/soapbox
Thanks for getting the fix to this problem in so quickly.
Best wishes,
--greg
On Tue, Jun 16, 2009 at 11:53 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
Using multiple EMs was not something I had considered when I wrote this.
I think that I can modify the code to provide a __nameSalt def to
differentiate instances. Let me work on it and I'll have something soon.
Derek
On 6/16/09, Jean-Luc jlcane...@gmail.com wrote:
For your information, here is an extract of source code of RequestVarEM
:
Trait RequestVarEM extends ScalaEntityManager with ScalaEMFactory {
object emVar extends RequestVar[EntityManager](openEM()) { ... }
}
EntityManager is stored in the singleton emVar; so, all db access of
Model objects are made using the singleton emVar.
= trait RequestVarEM allow only one connection to a database within the
same HttpRequest context.
Jean-Luc
2009/6/15 Jean-Luc jlcane...@gmail.com
Hello,
I have two databases, db1 (a.k.a. Motorbike) and db2 (a.k.a. Motorway)
defined with RequestVarEM :
- object ModelDb1 extends LocalEMF(db1) with RequestVarEM //
Motorbike database
- object ModelDb2 extends LocalEMF(db2) with RequestVarEM //
Motorway database
I thought one could access to any databases independently from any
snippet as long as the correct Model object were used (ModelDb1 or
ModelDb2
for exemple) ; but when I access both databases from the same page, the
second database access issues a Named query not found exception.
I have two snippets, one to display a list of motorbike, another to
display a list of motorway :
- page1 :
ModelDb1.createNamedQuery[Motorbike](Motorbike.findAll).getResultList()
=
ok
- page2
: ModelDb2.createNamedQuery[Motorway](Motorway.findAll).getResultList()
=
ok
- page3 : calling from page 3 motorbike motorway snippets : Named
query not found: Motorway.findAll
- page4 : calling from page 4 motorway motorbike snippets : Named
query not found: Motorbike.findAll
- page3 changing the query of *Motorway* snippet :
-
ModelDb2.createNamedQuery[*Motorbike*](*Motorbike*.findAll).getResultList()
= it's ok and I do NOT have an exception !
I joined a sample application, ...
any idea about this issue ?
(bad use of LocalEMF in the application code ? issue
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
You made an assumption and programmed a solution based on the knowledge you
had at the time. Thats fine and there is nothing wrong with it - start with
the simplest solution that fits. If it need to be changed due to changing
requirements, thats fine too. There is a tradeoff in creating a overly
complex solution that fits problems that you think might exist in the future
and simplicity. Also, there is nothing that makes composition an idea that
is only understood and relevant to functional programming as almost seems to
be suggested here.
On Wed, Jun 17, 2009 at 4:14 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:
I agree that it's an issue. In my own defense, what I meant was not that I
didn't think people would use more than one DB. I actually have several apps
(not yet converted to Lift) that use 4 or more persistence units that
represent various legacy databases. Rather, I failed to realize the problem
that would arise from defining the EM factory as a singleton because when I
wrote that code I didn't fully understand how member objects on classes
worked. Other than that, I agree with your post :)
Derek
On Tue, Jun 16, 2009 at 5:38 PM, Meredith Gregory
lgreg.mered...@gmail.com wrote:
Derek,
soapbox
You have just demonstrated a process that i have been talking about for
the last 15 years. People have a blind spot when it comes to thinking
compositionally. They think -- almost to a person -- about god's eye view
solutions where there's only one of some key solution component. They don't
think about solutions that are composed of ... (wait for it)... solutions!
It takes some serious training to think compositionally. Compositional
solutions, however, are the only realistic way to scale. When solutions are
compositional, you can *de*compose. The db example is a case in point.
One of the most natural ways to scale data access is sharding and
partitioning -- which requires upfront machinery to support decomposition of
the store.
Lest you feel bad, note that some of the best scientific minds of all time
have fallen prey to this blind spot. Newtonian physics as well as Einstein's
update to Newton's proposal is a non-compositional solution. Quantum
mechanics also exhibits compositional failures. This is why physics is
failing to find proposals that link theories of gravitation (essentially
large scale) to quantum mechanical theories of the other forces (essentially
very small scale) -- the physical theories are non-compositional -- they
don't scale!
One of the real things functional programming has going for it is that the
basic model of computation underlying the means of structuring and
manipulating programs is compositional. That's why it is important to have a
technology like Scala resting atop the incumbent execution model (JVM) being
deployed on web-scale problems. Compositionality is the only way to tackle
applications at global scale.
/soapbox
Thanks for getting the fix to this problem in so quickly.
Best wishes,
--greg
On Tue, Jun 16, 2009 at 11:53 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
Using multiple EMs was not something I had considered when I wrote this.
I think that I can modify the code to provide a __nameSalt def to
differentiate instances. Let me work on it and I'll have something soon.
Derek
On 6/16/09, Jean-Luc jlcane...@gmail.com wrote:
For your information, here is an extract of source code of RequestVarEM
:
Trait RequestVarEM extends ScalaEntityManager with ScalaEMFactory {
object emVar extends RequestVar[EntityManager](openEM()) { ... }
}
EntityManager is stored in the singleton emVar; so, all db access of
Model objects are made using the singleton emVar.
= trait RequestVarEM allow only one connection to a database within the
same HttpRequest context.
Jean-Luc
2009/6/15 Jean-Luc jlcane...@gmail.com
Hello,
I have two databases, db1 (a.k.a. Motorbike) and db2 (a.k.a. Motorway)
defined with RequestVarEM :
- object ModelDb1 extends LocalEMF(db1) with RequestVarEM //
Motorbike database
- object ModelDb2 extends LocalEMF(db2) with RequestVarEM //
Motorway database
I thought one could access to any databases independently from any
snippet as long as the correct Model object were used (ModelDb1 or
ModelDb2
for exemple) ; but when I access both databases from the same page, the
second database access issues a Named query not found exception.
I have two snippets, one to display a list of motorbike, another to
display a list of motorway :
- page1 :
ModelDb1.createNamedQuery[Motorbike](Motorbike.findAll).getResultList()
=
ok
- page2
: ModelDb2.createNamedQuery[Motorway](Motorway.findAll).getResultList()
=
ok
- page3 : calling from page 3 motorbike motorway snippets : Named
query not found: Motorway.findAll
- page4 : calling from page 4 motorway motorbike snippets : Named
query not found: Motorbike.findAll
- page3 changing the query of *Motorway* snippet :
-
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
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
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 tim.pig...@optrak.co.uk 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
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 dchenbec...@gmail.com
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 dchenbec...@gmail.com wrote:
Using multiple EMs was not something I had considered when I wrote this. I
think that I can modify the code to provide a __nameSalt def to
differentiate instances. Let me work on it and I'll have something soon.
Derek
On 6/16/09, Jean-Luc jlcane...@gmail.com wrote:
For your information, here is an extract of source code of RequestVarEM :
Trait RequestVarEM extends ScalaEntityManager with ScalaEMFactory {
object emVar extends RequestVar[EntityManager](openEM()) { ... }
}
EntityManager is stored in the singleton emVar; so, all db access of
Model objects are made using the singleton emVar.
= trait RequestVarEM allow only one connection to a database within the
same HttpRequest context.
Jean-Luc
2009/6/15 Jean-Luc jlcane...@gmail.com
Hello,
I have two databases, db1 (a.k.a. Motorbike) and db2 (a.k.a. Motorway)
defined with RequestVarEM :
- object ModelDb1 extends LocalEMF(db1) with RequestVarEM //
Motorbike database
- object ModelDb2 extends LocalEMF(db2) with RequestVarEM // Motorway
database
I thought one could access to any databases independently from any
snippet as long as the correct Model object were used (ModelDb1 or ModelDb2
for exemple) ; but when I access both databases from the same page, the
second database access issues a Named query not found exception.
I have two snippets, one to display a list of motorbike, another to
display a list of motorway :
- page1 :
ModelDb1.createNamedQuery[Motorbike](Motorbike.findAll).getResultList() =
ok
- page2
: ModelDb2.createNamedQuery[Motorway](Motorway.findAll).getResultList() =
ok
- page3 : calling from page 3 motorbike motorway snippets : Named
query not found: Motorway.findAll
- page4 : calling from page 4 motorway motorbike snippets : Named
query not found: Motorbike.findAll
- page3 changing the query of *Motorway* snippet :
-
ModelDb2.createNamedQuery[*Motorbike*](*Motorbike*.findAll).getResultList()
= it's ok and I do NOT have an exception !
I joined a sample application, ...
any idea about this issue ?
(bad use of LocalEMF in the application code ? issue with LocalEMF or
RequestVarEM ?)
Jean-Luc
PS :
I don't know if it's related but I have this in the log :
[INFO] Checking for multiple versions of scala
[WARNING] Multiple versions of scala libraries detected!
--
Jean-Luc Canela
jlcane...@gmail.com
--
Jean-Luc Canela
jlcane...@gmail.com
--
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
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
Isn't this just the result of JIT development? Don't need something
right now, don't implement it. If you need it later, refactor.
I'm probably looking at this too much from a low level grunt developer.
I understand that when developing a framework or anything with a public
API these are important issues, but that's what bugtrackers are for!
I'm all for composability, but it shouldn't be a religion :-) (--
please note the smiley!)
--Andrew
Derek Chen-Becker wrote:
I agree that it's an issue. In my own defense, what I meant was not
that I didn't think people would use more than one DB. I actually have
several apps (not yet converted to Lift) that use 4 or more
persistence units that represent various legacy databases. Rather, I
failed to realize the problem that would arise from defining the EM
factory as a singleton because when I wrote that code I didn't fully
understand how member objects on classes worked. Other than that, I
agree with your post :)
Derek
On Tue, Jun 16, 2009 at 5:38 PM, Meredith Gregory
lgreg.mered...@gmail.com mailto:lgreg.mered...@gmail.com wrote:
Derek,
soapbox
You have just demonstrated a process that i have been talking
about for the last 15 years. People have a blind spot when it
comes to thinking compositionally. They think -- almost to a
person -- about god's eye view solutions where there's only one
of some key solution component. They don't think about solutions
that are composed of ... (wait for it)... solutions! It takes some
serious training to think compositionally. Compositional
solutions, however, are the only realistic way to scale. When
solutions are compositional, you can _/de/_compose. The db example
is a case in point. One of the most natural ways to scale data
access is sharding and partitioning -- which requires upfront
machinery to support decomposition of the store.
Lest you feel bad, note that some of the best scientific minds of
all time have fallen prey to this blind spot. Newtonian physics as
well as Einstein's update to Newton's proposal is a
non-compositional solution. Quantum mechanics also exhibits
compositional failures. This is why physics is failing to find
proposals that link theories of gravitation (essentially large
scale) to quantum mechanical theories of the other forces
(essentially very small scale) -- the physical theories are
non-compositional -- they don't scale!
One of the real things functional programming has going for it is
that the basic model of computation underlying the means of
structuring and manipulating programs is compositional. That's why
it is important to have a technology like Scala resting atop the
incumbent execution model (JVM) being deployed on web-scale
problems. Compositionality is the only way to tackle applications
at global scale.
/soapbox
Thanks for getting the fix to this problem in so quickly.
Best wishes,
--greg
On Tue, Jun 16, 2009 at 11:53 AM, Derek Chen-Becker
dchenbec...@gmail.com mailto:dchenbec...@gmail.com wrote:
Using multiple EMs was not something I had considered when I
wrote this. I think that I can modify the code to provide a
__nameSalt def to differentiate instances. Let me work on it
and I'll have something soon.
Derek
On 6/16/09, *Jean-Luc* jlcane...@gmail.com
mailto:jlcane...@gmail.com wrote:
For your information, here is an extract of source code of
RequestVarEM :
Trait RequestVarEM extends ScalaEntityManager with
ScalaEMFactory {
object emVar extends
RequestVar[EntityManager](openEM()) { ... }
}
EntityManager is stored in the singleton emVar; so, all db
access of Model objects are made using the singleton emVar.
= trait RequestVarEM allow only one connection to a
database within the same HttpRequest context.
Jean-Luc
2009/6/15 Jean-Luc jlcane...@gmail.com
mailto:jlcane...@gmail.com
Hello,
I have two databases, db1 (a.k.a. Motorbike) and db2
(a.k.a. Motorway) defined with RequestVarEM :
- object ModelDb1 extends LocalEMF(db1) with
RequestVarEM // Motorbike database
- object ModelDb2 extends LocalEMF(db2) with
RequestVarEM // Motorway database
I thought one could access to any databases
independently from any snippet as long as the correct
Model object were used (ModelDb1 or ModelDb2 for
exemple) ; but when I access both databases from the
same page, the second database access issues a Named
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
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
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 π-calculihttp://en.wikipedia.org/wiki/Pi-calculusand lambda calculi http://en.wikipedia.org/wiki/Lambda_calculus suffer a dependence on a notion of name. Both families of calculi require at least countably infinitely http://en.wikipedia.org/wiki/Countable many nameshttp://www.cs.nps.navy.mil/research/languages/statements/gordon.html, and a notion of equality on names. If names have no internal structure then these theories *cannot be effectivehttp://en.wikipedia.org/wiki/Computable_function *. 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 computationhttp://svn.biosimilarity.com/src/open/papers/trunk/concurrency/rho/ex_nihilo_entcs/ex_nihilo_finco.pdf. 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 olambo...@gmail.com 2009/6/17 Meredith Gregory lgreg.mered...@gmail.com 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
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
On Wed, Jun 17, 2009 at 12:04 PM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
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 jorge.or...@gmail.comwrote:
In Derek's defense, it's not how objects in classes work but how Lift
RequestVars work. Scala objects in classes aren't global singletons, just
per-class-instance singletons. But a Lift ReuqestVar object in a class is
pretty much a global singleton (unless you do some hacking like Derek did).
--j
On Tue, Jun 16, 2009 at 11:14 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
I agree that it's an issue. In my own defense, what I meant was not that
I didn't think people would use more than one DB. I actually have several
apps (not yet converted to Lift) that use 4 or more persistence units that
represent various legacy databases. Rather, I failed to realize the problem
that would arise from defining the EM factory as a singleton because when I
wrote that code I didn't fully understand how member objects on classes
worked. Other than that, I agree with your post :)
Derek
On Tue, Jun 16, 2009 at 5:38 PM, Meredith Gregory
lgreg.mered...@gmail.com wrote:
Derek,
soapbox
You have just demonstrated a process that i have been talking about for
the last 15 years. People have a blind spot when it comes to thinking
compositionally. They think -- almost to a person -- about god's eye view
solutions where there's only one of some key solution component. They don't
think about solutions that are composed of ... (wait for it)... solutions!
It takes some serious training to think compositionally. Compositional
solutions, however, are the only realistic way to scale. When solutions are
compositional, you can *de*compose. The db example is a case in point.
One of the most natural ways to scale data access is sharding and
partitioning -- which requires upfront machinery to support decomposition
of
the store.
Lest you feel bad, note that some of the best scientific minds of all
time have fallen prey to this blind spot. Newtonian physics as well as
Einstein's update to Newton's proposal is a non-compositional solution.
Quantum mechanics also exhibits compositional failures. This is why physics
is failing to find proposals that link theories of gravitation (essentially
large scale) to quantum mechanical theories of the other forces
(essentially
very small scale) -- the physical theories are non-compositional -- they
don't scale!
One of the real things functional programming has going for it is that
the basic model of computation underlying the means of structuring and
manipulating programs is compositional. That's why it is important to have
a
technology like Scala resting atop the incumbent execution model (JVM)
being
deployed on web-scale problems. Compositionality is the only way to tackle
applications at global scale.
/soapbox
Thanks for getting the fix to this problem in so quickly.
Best wishes,
--greg
On Tue, Jun 16, 2009 at 11:53 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
Using multiple EMs was not something I had considered when I wrote
this. I think that I can modify the code to provide a __nameSalt def to
differentiate instances. Let me work on it and I'll have something soon.
Derek
On 6/16/09, Jean-Luc jlcane...@gmail.com wrote:
For your information, here is an extract of source code of
RequestVarEM :
Trait RequestVarEM extends ScalaEntityManager with ScalaEMFactory {
object emVar extends RequestVar[EntityManager](openEM()) { ... }
}
EntityManager is stored in the singleton emVar; so, all db access of
Model objects are made using the singleton emVar.
= trait RequestVarEM allow only one connection to a database within
the same HttpRequest context.
Jean-Luc
2009/6/15 Jean-Luc jlcane...@gmail.com
Hello,
I have two databases, db1 (a.k.a. Motorbike) and db2 (a.k.a.
Motorway) defined with RequestVarEM :
- object ModelDb1 extends LocalEMF(db1) with RequestVarEM //
Motorbike database
- object ModelDb2 extends LocalEMF(db2) with RequestVarEM //
Motorway database
I thought one could access to any databases independently from any
snippet as long as the correct Model object were used (ModelDb1 or
ModelDb2
for exemple) ; but when I access both databases from the same page, the
second database access issues a Named query not found exception.
I have two snippets, one to
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
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 tim.pig...@optrak.co.uk 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
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
2009/6/18 Meredith Gregory lgreg.mered...@gmail.com 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 π-calculihttp://en.wikipedia.org/wiki/Pi-calculusand lambda calculi http://en.wikipedia.org/wiki/Lambda_calculus suffer a dependence on a notion of name. Both families of calculi require at least countably infinitely http://en.wikipedia.org/wiki/Countable many nameshttp://www.cs.nps.navy.mil/research/languages/statements/gordon.html, and a notion of equality on names. If names have no internal structure then these theories *cannot be effectivehttp://en.wikipedia.org/wiki/Computable_function *. 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 computationhttp://svn.biosimilarity.com/src/open/papers/trunk/concurrency/rho/ex_nihilo_entcs/ex_nihilo_finco.pdf. 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 olambo...@gmail.com 2009/6/17 Meredith Gregory lgreg.mered...@gmail.com 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
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
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 http://en.wikipedia.org/wiki/Symmetry_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 http://en.wikipedia.org/wiki/Monad_%28category_theory%29 is
presented by three pieces of data:
- An endofunctor http://en.wikipedia.org/wiki/Functor M : C - C
(intuitively, think of M as a parametric type constructor and C as the
universe of types and maps)
- A natural
transformationhttp://en.wikipedia.org/wiki/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 olambo...@gmail.com
2009/6/18 Meredith Gregory lgreg.mered...@gmail.com
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
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
For your information, here is an extract of source code of RequestVarEM :
Trait RequestVarEM extends ScalaEntityManager with ScalaEMFactory {
object emVar extends RequestVar[EntityManager](openEM()) { ... }
}
EntityManager is stored in the singleton emVar; so, all db access of Model
objects are made using the singleton emVar.
= trait RequestVarEM allow only one connection to a database within the
same HttpRequest context.
Jean-Luc
2009/6/15 Jean-Luc jlcane...@gmail.com
Hello,
I have two databases, db1 (a.k.a. Motorbike) and db2 (a.k.a. Motorway)
defined with RequestVarEM :
- object ModelDb1 extends LocalEMF(db1) with RequestVarEM // Motorbike
database
- object ModelDb2 extends LocalEMF(db2) with RequestVarEM // Motorway
database
I thought one could access to any databases independently from any snippet
as long as the correct Model object were used (ModelDb1 or ModelDb2 for
exemple) ; but when I access both databases from the same page, the second
database access issues a Named query not found exception.
I have two snippets, one to display a list of motorbike, another to
display a list of motorway :
- page1 :
ModelDb1.createNamedQuery[Motorbike](Motorbike.findAll).getResultList() =
ok
- page2
: ModelDb2.createNamedQuery[Motorway](Motorway.findAll).getResultList() =
ok
- page3 : calling from page 3 motorbike motorway snippets : Named query
not found: Motorway.findAll
- page4 : calling from page 4 motorway motorbike snippets : Named query
not found: Motorbike.findAll
- page3 changing the query of *Motorway* snippet :
-
ModelDb2.createNamedQuery[*Motorbike*](*Motorbike*.findAll).getResultList()
= it's ok and I do NOT have an exception !
I joined a sample application, ...
any idea about this issue ?
(bad use of LocalEMF in the application code ? issue with LocalEMF or
RequestVarEM ?)
Jean-Luc
PS :
I don't know if it's related but I have this in the log :
[INFO] Checking for multiple versions of scala
[WARNING] Multiple versions of scala libraries detected!
--
Jean-Luc Canela
jlcane...@gmail.com
--
Jean-Luc Canela
jlcane...@gmail.com
--~--~-~--~~~---~--~~
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
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 dchenbec...@gmail.com wrote:
Using multiple EMs was not something I had considered when I wrote this. I
think that I can modify the code to provide a __nameSalt def to
differentiate instances. Let me work on it and I'll have something soon.
Derek
On 6/16/09, Jean-Luc jlcane...@gmail.com wrote:
For your information, here is an extract of source code of RequestVarEM :
Trait RequestVarEM extends ScalaEntityManager with ScalaEMFactory {
object emVar extends RequestVar[EntityManager](openEM()) { ... }
}
EntityManager is stored in the singleton emVar; so, all db access of Model
objects are made using the singleton emVar.
= trait RequestVarEM allow only one connection to a database within the
same HttpRequest context.
Jean-Luc
2009/6/15 Jean-Luc jlcane...@gmail.com
Hello,
I have two databases, db1 (a.k.a. Motorbike) and db2 (a.k.a. Motorway)
defined with RequestVarEM :
- object ModelDb1 extends LocalEMF(db1) with RequestVarEM // Motorbike
database
- object ModelDb2 extends LocalEMF(db2) with RequestVarEM // Motorway
database
I thought one could access to any databases independently from any
snippet as long as the correct Model object were used (ModelDb1 or ModelDb2
for exemple) ; but when I access both databases from the same page, the
second database access issues a Named query not found exception.
I have two snippets, one to display a list of motorbike, another to
display a list of motorway :
- page1 :
ModelDb1.createNamedQuery[Motorbike](Motorbike.findAll).getResultList() =
ok
- page2
: ModelDb2.createNamedQuery[Motorway](Motorway.findAll).getResultList() =
ok
- page3 : calling from page 3 motorbike motorway snippets : Named query
not found: Motorway.findAll
- page4 : calling from page 4 motorway motorbike snippets : Named query
not found: Motorbike.findAll
- page3 changing the query of *Motorway* snippet :
-
ModelDb2.createNamedQuery[*Motorbike*](*Motorbike*.findAll).getResultList()
= it's ok and I do NOT have an exception !
I joined a sample application, ...
any idea about this issue ?
(bad use of LocalEMF in the application code ? issue with LocalEMF or
RequestVarEM ?)
Jean-Luc
PS :
I don't know if it's related but I have this in the log :
[INFO] Checking for multiple versions of scala
[WARNING] Multiple versions of scala libraries detected!
--
Jean-Luc Canela
jlcane...@gmail.com
--
Jean-Luc Canela
jlcane...@gmail.com
--~--~-~--~~~---~--~~
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,
soapbox
You have just demonstrated a process that i have been talking about for the
last 15 years. People have a blind spot when it comes to thinking
compositionally. They think -- almost to a person -- about god's eye view
solutions where there's only one of some key solution component. They don't
think about solutions that are composed of ... (wait for it)... solutions!
It takes some serious training to think compositionally. Compositional
solutions, however, are the only realistic way to scale. When solutions are
compositional, you can *de*compose. The db example is a case in point. One
of the most natural ways to scale data access is sharding and partitioning
-- which requires upfront machinery to support decomposition of the store.
Lest you feel bad, note that some of the best scientific minds of all time
have fallen prey to this blind spot. Newtonian physics as well as Einstein's
update to Newton's proposal is a non-compositional solution. Quantum
mechanics also exhibits compositional failures. This is why physics is
failing to find proposals that link theories of gravitation (essentially
large scale) to quantum mechanical theories of the other forces (essentially
very small scale) -- the physical theories are non-compositional -- they
don't scale!
One of the real things functional programming has going for it is that the
basic model of computation underlying the means of structuring and
manipulating programs is compositional. That's why it is important to have a
technology like Scala resting atop the incumbent execution model (JVM) being
deployed on web-scale problems. Compositionality is the only way to tackle
applications at global scale.
/soapbox
Thanks for getting the fix to this problem in so quickly.
Best wishes,
--greg
On Tue, Jun 16, 2009 at 11:53 AM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
Using multiple EMs was not something I had considered when I wrote this. I
think that I can modify the code to provide a __nameSalt def to
differentiate instances. Let me work on it and I'll have something soon.
Derek
On 6/16/09, Jean-Luc jlcane...@gmail.com wrote:
For your information, here is an extract of source code of RequestVarEM :
Trait RequestVarEM extends ScalaEntityManager with ScalaEMFactory {
object emVar extends RequestVar[EntityManager](openEM()) { ... }
}
EntityManager is stored in the singleton emVar; so, all db access of Model
objects are made using the singleton emVar.
= trait RequestVarEM allow only one connection to a database within the
same HttpRequest context.
Jean-Luc
2009/6/15 Jean-Luc jlcane...@gmail.com
Hello,
I have two databases, db1 (a.k.a. Motorbike) and db2 (a.k.a. Motorway)
defined with RequestVarEM :
- object ModelDb1 extends LocalEMF(db1) with RequestVarEM // Motorbike
database
- object ModelDb2 extends LocalEMF(db2) with RequestVarEM // Motorway
database
I thought one could access to any databases independently from any
snippet as long as the correct Model object were used (ModelDb1 or ModelDb2
for exemple) ; but when I access both databases from the same page, the
second database access issues a Named query not found exception.
I have two snippets, one to display a list of motorbike, another to
display a list of motorway :
- page1 :
ModelDb1.createNamedQuery[Motorbike](Motorbike.findAll).getResultList() =
ok
- page2
: ModelDb2.createNamedQuery[Motorway](Motorway.findAll).getResultList() =
ok
- page3 : calling from page 3 motorbike motorway snippets : Named query
not found: Motorway.findAll
- page4 : calling from page 4 motorway motorbike snippets : Named query
not found: Motorbike.findAll
- page3 changing the query of *Motorway* snippet :
-
ModelDb2.createNamedQuery[*Motorbike*](*Motorbike*.findAll).getResultList()
= it's ok and I do NOT have an exception !
I joined a sample application, ...
any idea about this issue ?
(bad use of LocalEMF in the application code ? issue with LocalEMF or
RequestVarEM ?)
Jean-Luc
PS :
I don't know if it's related but I have this in the log :
[INFO] Checking for multiple versions of scala
[WARNING] Multiple versions of scala libraries detected!
--
Jean-Luc Canela
jlcane...@gmail.com
--
Jean-Luc Canela
jlcane...@gmail.com
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
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
lgreg.mered...@gmail.comwrote:
Derek,
soapbox
You have just demonstrated a process that i have been talking about for the
last 15 years. People have a blind spot when it comes to thinking
compositionally. They think -- almost to a person -- about god's eye view
solutions where there's only one of some key solution component. They don't
think about solutions that are composed of ... (wait for it)... solutions!
It takes some serious training to think compositionally. Compositional
solutions, however, are the only realistic way to scale. When solutions are
compositional, you can *de*compose. The db example is a case in point. One
of the most natural ways to scale data access is sharding and partitioning
-- which requires upfront machinery to support decomposition of the store.
Lest you feel bad, note that some of the best scientific minds of all time
have fallen prey to this blind spot. Newtonian physics as well as Einstein's
update to Newton's proposal is a non-compositional solution. Quantum
mechanics also exhibits compositional failures. This is why physics is
failing to find proposals that link theories of gravitation (essentially
large scale) to quantum mechanical theories of the other forces (essentially
very small scale) -- the physical theories are non-compositional -- they
don't scale!
One of the real things functional programming has going for it is that the
basic model of computation underlying the means of structuring and
manipulating programs is compositional. That's why it is important to have a
technology like Scala resting atop the incumbent execution model (JVM) being
deployed on web-scale problems. Compositionality is the only way to tackle
applications at global scale.
/soapbox
Thanks for getting the fix to this problem in so quickly.
Best wishes,
--greg
On Tue, Jun 16, 2009 at 11:53 AM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
Using multiple EMs was not something I had considered when I wrote this. I
think that I can modify the code to provide a __nameSalt def to
differentiate instances. Let me work on it and I'll have something soon.
Derek
On 6/16/09, Jean-Luc jlcane...@gmail.com wrote:
For your information, here is an extract of source code of RequestVarEM :
Trait RequestVarEM extends ScalaEntityManager with ScalaEMFactory {
object emVar extends RequestVar[EntityManager](openEM()) { ... }
}
EntityManager is stored in the singleton emVar; so, all db access of
Model objects are made using the singleton emVar.
= trait RequestVarEM allow only one connection to a database within the
same HttpRequest context.
Jean-Luc
2009/6/15 Jean-Luc jlcane...@gmail.com
Hello,
I have two databases, db1 (a.k.a. Motorbike) and db2 (a.k.a. Motorway)
defined with RequestVarEM :
- object ModelDb1 extends LocalEMF(db1) with RequestVarEM //
Motorbike database
- object ModelDb2 extends LocalEMF(db2) with RequestVarEM // Motorway
database
I thought one could access to any databases independently from any
snippet as long as the correct Model object were used (ModelDb1 or ModelDb2
for exemple) ; but when I access both databases from the same page, the
second database access issues a Named query not found exception.
I have two snippets, one to display a list of motorbike, another to
display a list of motorway :
- page1 :
ModelDb1.createNamedQuery[Motorbike](Motorbike.findAll).getResultList() =
ok
- page2
: ModelDb2.createNamedQuery[Motorway](Motorway.findAll).getResultList() =
ok
- page3 : calling from page 3 motorbike motorway snippets : Named
query not found: Motorway.findAll
- page4 : calling from page 4 motorway motorbike snippets : Named
query not found: Motorbike.findAll
- page3 changing the query of *Motorway* snippet :
-
ModelDb2.createNamedQuery[*Motorbike*](*Motorbike*.findAll).getResultList()
= it's ok and I do NOT have an exception !
I joined a sample application, ...
any idea about this issue ?
(bad use of LocalEMF in the application code ? issue with LocalEMF or
RequestVarEM ?)
Jean-Luc
PS :
I don't know if it's related but I have this in the log :
[INFO] Checking for multiple versions of scala
[WARNING] Multiple versions of scala libraries detected!
--
Jean-Luc Canela
jlcane...@gmail.com
--
Jean-Luc Canela
jlcane...@gmail.com
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
[Lift] Re: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database
Greg, On Tue, Jun 16, 2009 at 6:38 PM, Meredith Gregory lgreg.mered...@gmail.comwrote: 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
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 jeremy@gmail.com 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
2009/6/17 Meredith Gregory lgreg.mered...@gmail.com 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 jeremy@gmail.com 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 -~--~~~~--~~--~--~---
