incubator-empire-db-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francis De Brabandere <franci...@gmail.com>
Subject Re: Scala inter-op issue [Was: Importing XML]
Date Fri, 16 Oct 2009 17:39:21 GMT
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 <acooke.org@gmail.com> 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 <francisdb@gmail.com>:
>> 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 <acooke.org@gmail.com> 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 <francisdb@gmail.com>:
>>>> 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 <acooke.org@gmail.com>
wrote:
>>>>> Sorry, no - my fault.  I was using getRecordData instead of open.  Andrew
>>>>>
>>>>> 2009/10/13 andrew cooke <acooke.org@gmail.com>:
>>>>>> 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.

Mime
View raw message