That took care of the compile issues. Thanks, Ross.
Craig
On Mar 8, 2010, at 11:05 PM, Ross Mellgren wrote:
So I looked into this as best I could and it seems to be a type inference
error where the compiler is inferring a too-loose type binding for EnumType
and therefore rejecting the
Writing into the database with the new field type works fine, but I'm running
into a little hitch trying to access the value. Given the test code (again
this is in the Github test project,
g...@github.com:craigwblake/lift-couchdb-test.git):
object TestEnum extends Enumeration { val
I'll have to look at this in more detail tonight. I took a quick couple hacks
at it and I can honestly say I have no idea what kind of problem the Scala
compiler is trying to tell you about :-/
If you avoid types, they clearly are of the same type and value (e.g.
So I looked into this as best I could and it seems to be a type inference error
where the compiler is inferring a too-loose type binding for EnumType and
therefore rejecting the assignment to a (supposedly) more specific
Box[TestEnum.Value].
I have no idea how to fix the code so it deduces the
Ok, thanks for the hint. I clean compiled each Scala library that touches the
project (including lift), and made sure that their are no conflicting versions
of Scala in the path (I checked with the Maven dependency plugin, and I do not
get the warning that multiple versions were detected) but
To test further, I've created a simple test project with only one dependency,
lift-couchdb, and this code:
object Settings extends Settings with CouchMetaRecord[ Settings]
class Settings extends CouchRecord[ Settings] {
def meta = Settings
object updated extends
If JSONRecord generates a runtime AbstractMethodError, compiling it with the
same classpath would generate a compiler error.
Do you know what that test.Settings... line is referring to? If not look up the
line mentioned. Something about that reference is different between compile
time and
I can reproduce this locally, and offhand looks like a scala compiler bug (this
should never have compiled).
I have to run right now, but I'll look at in ~2-4 hours and hopefully figure it
out for you.
-Ross
On Mar 4, 2010, at 1:28 PM, Craig Blake wrote:
To test further, I've created a
Great, thanks for taking the time to look into it!
Craig
On Mar 4, 2010, at 2:23 PM, Ross Mellgren wrote:
I can reproduce this locally, and offhand looks like a scala compiler bug
(this should never have compiled).
I have to run right now, but I'll look at in ~2-4 hours and hopefully
Remind me which versions of Lift and Scala you're using?
-
Craig Blakecraigwbl...@gmail.com wrote:
To test further, I've created a simple test project with only one dependency,
lift-couchdb, and this code:
object Settings extends Settings with
I'm using Lift trunk and the Scala version it pulls in, which I think end up
being 2.0-SNAPSHOT and 2.7.7 respectively. The only change to Lift I have is
Ross's new enum field from earlier in this thread.
Craig
On Mar 4, 2010, at 2:31 PM, Naftoli Gugenheim wrote:
Remind me which versions of
Okay, type erasure ate your lunch. I have a patched version locally that
apparently works -- your code on my machine gets to invalid username or
password accessing Couch, which indicates it got past the previous problem.
I'd love it if you could apply this patch to your local trunk and give it
Looks like that did it. The test project works for me and successfully writes
to the DB. I'll also give it a run with the full code I was working on and let
you know if I run into any problems.
Thanks for the fast fix!
Craig
On Mar 4, 2010, at 3:47 PM, Ross Mellgren wrote:
Okay, type
Yep, both the date-time and enumeration-by-name fields work like a charm in my
real code as well.
Thanks again.
Craig
On Mar 4, 2010, at 3:47 PM, Ross Mellgren wrote:
Okay, type erasure ate your lunch. I have a patched version locally that
apparently works -- your code on my machine gets
Unfortunately the compiler error is bizarre (due to some of the type shuffling
involved), but the underlying problem you're experiencing is that
DateTimeFields (and therefore JSONDateTimeFields) have a storage type of
Calendar, and you're trying to assign a Date to them. Try
Yep, that seems to be better. Sorry for the noise, I don't know why I didn't
think to check that.
Thanks for the quick answer.
Craig
On Mar 3, 2010, at 4:44 PM, Ross Mellgren wrote:
Unfortunately the compiler error is bizarre (due to some of the type
shuffling involved), but the
It's no problem, as I mentioned the compiler error is practically useless.
Hope you get along well, let me know if you have any other issues.
-Ross
On Mar 3, 2010, at 7:29 PM, Craig Blake wrote:
Yep, that seems to be better. Sorry for the noise, I don't know why I didn't
think to check
Sure, will do. The only thing I think I'll need to figure out is how to
persist an enumeration by name rather than ordinal value, but I imagine that it
should be pretty straight-forward to add a new field type in my app to handle
it.
Thanks,
Craig
On Mar 3, 2010, at 7:45 PM, Ross Mellgren
Try this:
/** Enum data field for JSON records. Encodes as JString */
class JSONEnumNameField[OwnerType : JSONRecord[OwnerType], EnumType :
Enumeration]
(rec: OwnerType, enum: EnumType)(implicit enumValueType:
Manifest[EnumType#Value])
extends EnumField[OwnerType,
Just took a minor change to compile (didn't like ?~) and I'll let you know how
it goes soon. I'm running into one more problem, this time a runtime exception
saving a document:
java.lang.AbstractMethodError:
test.Settings$updated$.encode(Ljava/lang/Object;)Ljava/lang/String;
at
AbstractMethodError means you need to do a clean build and make sure you don't
have multiple scala versions.
-
Craig Blakecraigwbl...@gmail.com wrote:
Just took a minor change to compile (didn't like ?~) and I'll let you know how
it goes soon. I'm running
21 matches
Mail list logo
