Immutable fields are (now) supported (was Re: Bug with case classes)
Maxime Lévesque
It turned out that the theory was a bit ahead of the reality :
There was a case where an immutable field combined with
inheritance was causing a bug.
I commited the fix and updated the _latest-head.jar.
I also changed part of the test suite to use immutable fields.
...Pardon me Eric if I call my test code a 'test suite'...
I've been thinking about switching to a real test framework
for a while ! Specs seemed like the best choice since it
allows testing for the non compilation of "deliquent" code,
is that correct ?
Now the doc needs to be updated to not give the impression
that var's are the only supported choice ! ;-)
Cheers
When you say getting rid of the vars, do you mean replacing them
by vals in order to make the classes immutable ?
It should work in theory ! ;-)
I'm adding test in my test suite it order to know if it's supported in practice ;-)
Stayed tuned for the results ...
MaxOn Wed, Feb 24, 2010 at 5:04 PM, etorreborre <etorr...@gmail.com> wrote:
Thanks a lot Maxime,
BTW, could you share your thoughts about getting rid of the var's
declaration in the persisted classes?
I've seen that the Lift crew has also noticed this and suggested that
the new copy method of 2.8 case classes may be helping here.
E.
On Feb 24, 9:28 pm, Maxime Lévesque <maxime.leves...@gmail.com> wrote:
> Hi Erric, I just commited a fix in the GitHub and
> included case classes in my test suite.
>
> This is Squeryl's first community submitted bug... what a historic moment !
> ;-)
>
> Thanks !
>
>
>
> On Wed, Feb 24, 2010 at 4:55 AM, etorreborre <etorrebo...@gmail.com> wrote:
> > Hi Maxime,
>
> > First of all, thanks for delivering an easy-to-use and elegant
> > solution to JDBC access in Scala!
>
> > I've been starting to use it because I need exactly that, now.
>
> > However I've hit what seems to be a bug. I want to use case classes to
> > get the usual additional methods like equals generated for me but I
> > get this stacktrace:
>
> > java.util.NoSuchElementException: None.get
> > at scala.None$.get(Option.scala:186)
> > at scala.None$.get(Option.scala:184)
> > at org.squeryl.internals.PosoMetaData.org$squeryl$internals
> > $PosoMetaData$$_groupOfMembersIsProperty(PosoMetaData.scala:222)
> > at org.squeryl.internals.PosoMetaData$$anonfun$buildFieldMetaData
> > $4.apply(PosoMetaData.scala:192)
> > at org.squeryl.internals.PosoMetaData$$anonfun$buildFieldMetaData
> > $4.apply(PosoMetaData.scala:161)
> > at scala.collection.MapLike$$anon$2$$anonfun$foreach
> > $7.apply(MapLike.scala:249)
> > at scala.collection.MapLike$$anon$2$$anonfun$foreach
> > $7.apply(MapLike.scala:249)
> > at scala.collection.Iterator$class.foreach(Iterator.scala:582)
> > at scala.collection.Iterator$$anon$19.foreach(Iterator.scala:325)
> > at
> > scala.collection.IterableLike$class.foreach(IterableLike.scala:83)
> > at scala.collection.immutable.HashMap.foreach(HashMap.scala:37)
> > at scala.collection.MapLike$$anon$2.foreach(MapLike.scala:249)
> > at
> > org.squeryl.internals.PosoMetaData.buildFieldMetaData(PosoMetaData.scala:
> > 161)
> > at org.squeryl.internals.PosoMetaData.<init>(PosoMetaData.scala:35)
> > at org.squeryl.View.<init>(View.scala:17)
> > at org.squeryl.Table.<init>(Table.scala:10)
> > at org.squeryl.Table.<init>(Table.scala:13)
> > at org.squeryl.Schema$class.table(Schema.scala:76)
>
> > Any idea? A fix?
>
> > Thanks,
>
> > Eric.
etorreborre
Thanks for such a fast turn-around. I'm going to test this out on my
pet project.
>...Pardon me Eric if I call my test code a 'test suite'...
>I've been thinking about switching to a real test framework
>for a while ! Specs seemed like the best choice since it
>allows testing for the non compilation of "deliquent" code,
>is that correct ?
Yes you can do that by using code "snippets" which can be evaluated
using the interpreter.
This is not fully documented and you'll have to look in the code and
examples for the ScalaInterpreter and Snippets traits.
Don't hesitate to ask if you have any question on this.
> Now the doc needs to be updated to not give the impression
> that var's are the only supported choice ! ;-)
That's an important "marketing" point. Scala is also about the
possibility of embracing the functional paradigm, right ;-) ?
E.
On Feb 25, 2:15 pm, Maxime Lévesque <maxime.leves...@gmail.com> wrote:
> It turned out that the theory was a bit ahead of the reality :
>
> There was a case where an immutable field combined with
> inheritance was causing a bug.
>
> I commited the fix and updated the _latest-head.jar.
>
> I also changed part of the test suite to use immutable fields.
>
> ...Pardon me Eric if I call my test code a 'test suite'...
> I've been thinking about switching to a real test framework
> for a while ! Specs seemed like the best choice since it
> allows testing for the non compilation of "deliquent" code,
> is that correct ?
>
> Now the doc needs to be updated to not give the impression
> that var's are the only supported choice ! ;-)
>
> Cheers
>
> 2010/2/24 Maxime Lévesque <maxime.leves...@gmail.com>
>
>
>
>
>
> > When you say getting rid of the vars, do you mean replacing them
> > by vals in order to make the classes immutable ?
>
> > It should work in theory ! ;-)
>
> > I'm adding test in my test suite it order to know if it's supported in
> > practice ;-)
>
> > Stayed tuned for the results ...
>
> > Max
>
Ravi Mendis
I've found that performing a Squeryl update over a immutable field
works.
How is this correct?
I should have thought that an exception should be thrown or something,
no?
I've since changed my schema to have a mutable field i.e a var in
place of val, but i'm curious as to why it worked when it was a val...
Thx
Maxime Lévesque
I am guessing that you used this update syntax :
update(aTable)(t =>
set(t.aField := aValue)
)
because the compiler won't let you use the other scheme (update a val).
The above works with val fields because the object passed to the closure
never gets modified, the only thing happending is an AST construction,
and the corresponding update statement get's sent on the DB.
I might have misunderstood your question, if so, send a snipet
of code with the update in question along with your class.
Cheers !
Ravi Mendis
On Mar 3, 2:35 pm, Maxime Lévesque <maxime.leves...@gmail.com> wrote:
> I am guessing that you used this update syntax :
>
> update(aTable)(t =>
> set(t.aField := aValue)
> )
That's correct.
Ok. I understand now...
Thx