I'll be speaking for myself and Kajo. You've already heard some of these answers from me, but you'll have it at one place at least...
On Jun 10, 2011, at 1:10 , David Whittaker wrote:
> I've been looking into a few issues involving Squeryl/Record and Lift transactions (DB.use) recently. The two main issues I see are 1) There is no way to detect when a Lift transaction ends in order to clean up external resources and 2) Squeryl doesn't have the concept of more than one DB in use per application.
I'm not happy to hear that. I'm preparing one feature that I was thinking would use and connect to second DB
> One solution would be to add the appropriate integration points in the Lift transaction lifecycle and accept that Squeryl won't completely support all DB.use features, but I wonder if this is really necessary. For the Squeryl/Record users out there, how many of you are using Lift transactions as opposed to Squeryl transactions?
We don't use Lift transactions any more...
> If you are using Lift transactions, why did you choose them?
We chose it as it seemed easier, coming from Mapper world.
> If I were to add better integration of Squeryl transactions with Lift (think SquerylRecord.buildLoanWrapper) does anyone see a need to maintain the Lift transaction support?
IMHO no, there isn't. It took me about half an hour to switch (just rewrite initialization, custom loan wrapper and place transaction{} instead of DB.use at places where I needed specific transactions) and it provides me everything I need so far.
> Is there a feature of Lift transactions that you need that Squeryl doesn't offer, or are any of you using Squeryl and Mapper side by side?
Possibly connection pooling but that can be achieved by other means. And it'd be nice to have multiple DBs
> I'm far from a decision on this and I'd like some feedback from the community on what you all think would be best.
>
> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
We're not using Squeryl atm, but I'm considering it (or something
else) in the future
We've started out with Mapper (and thus Lift transactions) since it
was fast & easy to get something up and running but as complexity
grows, the ActiveRecord style is not really sufficient anymore and so
we're gradually moving more towards a CQRS-like architecture.
I know nothing about the Squeryl transactions yet, but would think
there could be some value (for us at least :-) to be able to use
Mapper & Squeryl side by side
/Jeppe
Hi Dave,
I'll be speaking for myself and Kajo. You've already heard some of these answers from me, but you'll have it at one place at least...
I'm not happy to hear that. I'm preparing one feature that I was thinking would use and connect to second DB
On Jun 10, 2011, at 1:10 , David Whittaker wrote:
> I've been looking into a few issues involving Squeryl/Record and Lift transactions (DB.use) recently. The two main issues I see are 1) There is no way to detect when a Lift transaction ends in order to clean up external resources and 2) Squeryl doesn't have the concept of more than one DB in use per application.
We don't use Lift transactions any more...
> One solution would be to add the appropriate integration points in the Lift transaction lifecycle and accept that Squeryl won't completely support all DB.use features, but I wonder if this is really necessary. For the Squeryl/Record users out there, how many of you are using Lift transactions as opposed to Squeryl transactions?
We chose it as it seemed easier, coming from Mapper world.
> If you are using Lift transactions, why did you choose them?
IMHO no, there isn't. It took me about half an hour to switch (just rewrite initialization, custom loan wrapper and place transaction{} instead of DB.use at places where I needed specific transactions) and it provides me everything I need so far.
> If I were to add better integration of Squeryl transactions with Lift (think SquerylRecord.buildLoanWrapper) does anyone see a need to maintain the Lift transaction support?
Possibly connection pooling but that can be achieved by other means. And it'd be nice to have multiple DBs
> Is there a feature of Lift transactions that you need that Squeryl doesn't offer, or are any of you using Squeryl and Mapper side by side?
We're not using Squeryl atm, but I'm considering it (or something
else) in the future
We've started out with Mapper (and thus Lift transactions) since it
was fast & easy to get something up and running but as complexity
grows, the ActiveRecord style is not really sufficient anymore and so
we're gradually moving more towards a CQRS-like architecture.
I know nothing about the Squeryl transactions yet, but would think
there could be some value (for us at least :-) to be able to use
Mapper & Squeryl side by side
/Jeppe
I'm not happy to hear that. I'm preparing one feature that I was thinking would use and connect to second DB
On Fri, Jun 10, 2011 at 2:43 AM, Ján Raska <ras...@gmail.com> wrote:I'm not happy to hear that. I'm preparing one feature that I was thinking would use and connect to second DBJán,Just wanted to point out for you and anyone else who is interested in using Squeryl with more than one DB that Max gave a much better explanation on how to do it than mine on the Squeryl list:
All,I'm a bit surprised that I haven't gotten more reaction to this. Are most of you using Squeryl transactions already rather than DB.use style?
Just for another data point, we're using Squeryl transactions and
multiple databases (w/o Record though). We're using basically the
approach Max outlines above. It is wrapped in our own API though to
make it easier to stub out transaction management in a test
environment.
I do vaguely remember some issues with DB.use when we first got
started, but my recollection is vague enough that I didn't think it
was worth chiming in. It could have been user error too.
Pete
+1 to the loanwrapper model for running transactions.
Out of curiosity, does you approach mean separating the notions of connecting to a database and starting a transaction? This would be really useful for e.g. acceptance testing, where the tests are running in a separate process from the code under test. In other words:
beginAcceptanceTest {
connectToDatabase {
// This line runs in its own one-line transaction:
val user = User.createRecord.save
// The web site can see data created on the previous line even though we haven't disconnected from the DB:
makeRemoteWebSiteDoSomething
withTransaction {
// Code in here runs in a transaction, so just for the sake of illustration:
var otherUser = User.createRecord.save
// The web site *wouldn't* be able to see otherUser because the transaction isn't committed:
makeRemoteWebSiteDoSomething
}
// etc ...
}
}
As far as I can tell this is a drawback with DB.use (I've inferred this myself rather than read it anywhere, so apologies if I've misunderstood how DB.use works).
Cheers,
-- Dave