On Sun, Mar 7, 2010 at 12:47 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:
Based on discussion on Review Board item 247, I want to propose the
following change to the organization of Mapper specs.
Currently there are four files in
I'm not 100% clear on your proposal.
First of all, is what I've done (on RB) in the meantime okay (without a
ticket)? Basically, I renamed ItemsListSpecs to MapperSpecs2 and put the test
for issue 370 there. MapperSpecs2 only uses H2 memory db. (Any suggestions for
a better name?)
As for your
On Mar 8, 2010, at 3:00 PM, Naftoli Gugenheim wrote:
I'm not 100% clear on your proposal.
First of all, is what I've done (on RB) in the meantime okay (without a
ticket)? Basically, I renamed ItemsListSpecs to MapperSpecs2 and put the test
for issue 370 there. MapperSpecs2 only uses H2
On Mon, Mar 8, 2010 at 1:00 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:
I'm not 100% clear on your proposal.
First of all, is what I've done (on RB) in the meantime okay (without a
ticket)? Basically, I renamed ItemsListSpecs to MapperSpecs2 and put the
test for issue 370 there.
Currently what I did is combine ItemListSpecs with another test, so I gave it a
more generic name than ItemsList, hence MapperSpecs2. The idea is that some
tests really have zero to do with the vendor, but higher-level behavior.
H2MemoryProvider is incidental--in memory databases are perfect
DriverIndependentSpecs?
-Ross
On Mar 8, 2010, at 3:59 PM, Naftoli Gugenheim wrote:
Currently what I did is combine ItemListSpecs with another test, so I gave it
a more generic name than ItemsList, hence MapperSpecs2. The idea is that some
tests really have zero to do with the vendor, but
On Mon, Mar 8, 2010 at 1:59 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:
Currently what I did is combine ItemListSpecs with another test, so I gave
it a more generic name than ItemsList, hence MapperSpecs2. The idea is that
some tests really have zero to do with the vendor, but
Not sure -- it sounded like you were describing a scenario with separate test
files for each combination of area being tested and driver, where I was
describing combining multiple areas in one file (like MapperSpecs is now).
Maybe I misunderstood.
-
Jim
On Mon, Mar 8, 2010 at 2:16 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:
Not sure -- it sounded like you were describing a scenario with separate
test files for each combination of area being tested and driver, where I was
describing combining multiple areas in one file (like MapperSpecs
On Mon, Mar 8, 2010 at 12:00 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:
I'm not 100% clear on your proposal.
First of all, is what I've done (on RB) in the meantime okay (without a
ticket)?
What part of Please open a ticket first before putting stuff on RB. is
unclear?
You've consumed
Based on discussion on Review Board item 247, I want to propose the following
change to the organization of Mapper specs.
Currently there are four files in
framework/lift-persistence/lift-mapper/src/test/scala/net/liftweb/mapper:
DBProviders - initalization for each provider to be tested
11 matches
Mail list logo
