incubator-empire-db-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From andrew cooke <>
Subject Re: Scala inter-op issue
Date Sun, 25 Oct 2009 22:06:31 GMT

Thanks - no problem with the delay, I have everything working
perfectly at the moment (as far as I know) - I just subclassed DBTable
to implement my own clone method.


2009/10/25 Rainer Döbele <>:
> Hi Andrew,
> I know I am a bit late with my answer to this problem, but I just have not been able
to reply earlier.
> First you are right that the intention of the clone method is to allow self-joins, i.e.
the clone is an exact copy of the original with the exception of using a different table alias.
> Instead of using clone() you can simply create a second instance of the table that you
need to self-join.
>  MyTable t1 = new MyTable(db);
>  MyTable t2 = new MyTable(db);
> Since in most cases where you need to self-join a table you have a corresponding foreign-key
representing a self-reference I recommend creating a second instance with the database and
make it accessible through a field or property.
> Although personally I prefer this approach from using clone(), of course clone() should
work too.
> And indeed it looks like there is a problem when cloning the columns if they have been
declared in a superclass.
> I will investigate this a bit further and fix this issue.
> Thanks,
> Rainer
> andrew cooke wrote:
>> re: Scala inter-op issue [Was: Importing XML]
>> 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 <>:
>> > 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 <>
>> wrote:
>> >> Sorry, no - my fault.  I was using getRecordData instead of open.
>>  Andrew
>> >>
>> >> 2009/10/13 andrew cooke <>:
>> >>> 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.
>> >>
>> >
>> >
>> >
>> > --
>> >
>> > Microsoft gives you windows, Linux gives you the whole house.
>> >

View raw message