Yes - the code for that is here - http://code.google.com/p/uykfd/source/browse/src/main/scala/org/acooke/uykfd/lastfm/TopTags.scala
There's not much to see - I'm just calling one of the APIs via the Jersey library (std Java API for REST web services). And Scala has "built in" XML support which makes processing the response trivial. Andrew 2009/10/16 Francis De Brabandere <[email protected]>: > Nice, I'll have a look at your code later. Looks like an interesting > project, do you plan last.fm integration? Thanks > > On Fri, Oct 16, 2009 at 3:00 PM, andrew cooke <[email protected]> wrote: >> I don't have a test, I'm afraid (this is a very quick + dirty project, >> but if I do end up adding tests I'll get back to you). >> >> However, I do have a solution to the problem, which is to subclass >> DBTable in Scala, as done here - >> http://code.google.com/p/uykfd/source/browse/src/main/scala/org/acooke/uykfd/db/ScalaTable.scala?spec=svn1d698e907d846e4d7b152bfe129903e9174714a8&r=1d698e907d846e4d7b152bfe129903e9174714a8 >> >> Also, I think columns must be "var" (mutable). There's a schema in >> Scala that uses the table above here - >> http://code.google.com/p/uykfd/source/browse/src/main/scala/org/acooke/uykfd/db/Schema.scala?spec=svn86f651a3ceff7404c34a35d9985c7992abd1b42b&r=86f651a3ceff7404c34a35d9985c7992abd1b42b >> >> You could modify the DBTable code directly to address this by placing >> the following code in the "catch" for an illegal access exception (in >> the clone method): >> >> val getter = getClass.getDeclaredMethod(fields(j).getName) >> if (getter.invoke(clone) == srcCol) { >> val setter = getClass.getDeclaredMethod(fields(j).getName + "_$eq", tipe) >> setter.invoke(clone, newCol) >> } >> >> (that's in Scala, but the translation to Java is obvious if you have >> used Java's reflection API). All the above does is use the method >> name to infer and access the auto-generated getter/setter (the getter >> has the same name as the attribute, the setter has "_$eq" appended). >> >> With that, my SQL generation appears to work fine (apart from logging >> messages from the super.clone, which thinks it has failed). >> >> Cheers, >> Andrew >> >> 2009/10/16 Francis De Brabandere <[email protected]>: >>> Hi Andrew, >>> >>> Since I'm also interested in scala I think it would be nice to >>> actually have a scala example in our examples module. Would you be >>> able and willing to create a scala version of our current simple >>> example? I suppose we can set up maven to use scala. >>> >>> I don't have a good enough view on the framework to help you with the >>> problem. I've mostly been taken care of the maven build. But Rainer >>> will probably be able to answer your question. >>> >>> Cheers, >>> Francis >>> >>> >>> On Fri, Oct 16, 2009 at 2:07 AM, andrew cooke <[email protected]> wrote: >>>> Hi, >>>> >>>> I just hit quite a serious issue for using Empire DB in Scala which I >>>> thought I would flag, since you asked. >>>> >>>> The clone() method of DBTable (and perhaps any other clone method that >>>> might be used) requires access to the attributes of an object (so that >>>> it can copy columns). Unfortunately in Scala the attributes of an >>>> instance are always private. It doesn't appear that way in Scala >>>> code, because Scala automatically generates matching getters and >>>> setters (that, simplifying slightly, have the same name as the >>>> attribute - it sounds odd, but Scala has some unusual syntax that >>>> makes it work). >>>> >>>> This means that cloning fails, because the private attribute generates >>>> an illegal access exception. So any query that uses a table twice >>>> (with different aliases) cannot be expressed in Empire DB (at least, I >>>> assume this is solved by using DBTable.clone() - I have not yet got it >>>> to work, for this reason). >>>> >>>> I can write my own clone function, I hope, once I learn some more >>>> about Scala, or I can define my schema in Java. So this is not a >>>> deal-breaker for me, but it would make using Empire DB from Scala much >>>> simpler if the clone method either: >>>> 1 - checked for the Scala syntax and used the Scala getters/setters or >>>> 2 - provided a separate method (cloneScala?) that used the Scala >>>> getters/setters >>>> >>>> It is possible to make Scala objects conform to JavaBean standards, so >>>> another solution would be to use setters that follow that convention, >>>> but the code would be uglier in Scala and never used from Java, so I >>>> don't think that is a good idea. >>>> >>>> Cheers, >>>> Andrew >>>> >>>> >>>> 2009/10/13 Francis De Brabandere <[email protected]>: >>>>> Hi andrew, >>>>> >>>>> A bit offtopic. Do you use scala a lot? Do you think it is the future >>>>> for java? Would there be a need for empire-db - scala integration >>>>> code? >>>>> >>>>> Thanks, >>>>> Francis >>>>> >>>>> On Tue, Oct 13, 2009 at 2:17 PM, andrew cooke <[email protected]> >>>>> wrote: >>>>>> Sorry, no - my fault. I was using getRecordData instead of open. Andrew >>>>>> >>>>>> 2009/10/13 andrew cooke <[email protected]>: >>>>>>> Also, the dump is missing the first element of each table. I believe >>>>>>> that is a bug in Empire DB, but I will first try to reproduce it in >>>>>>> Java and then file a report with a simple example. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> http://www.somatik.be >>>>> Microsoft gives you windows, Linux gives you the whole house. >>>>> >>>> >>> >>> >>> >>> -- >>> http://www.somatik.be >>> Microsoft gives you windows, Linux gives you the whole house. >>> >> > > > > -- > http://www.somatik.be > Microsoft gives you windows, Linux gives you the whole house. >
