You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@empire-db.apache.org by andrew cooke <ac...@gmail.com> on 2009/10/16 02:07:56 UTC
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 <fr...@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 <ac...@gmail.com> wrote:
>> Sorry, no - my fault. I was using getRecordData instead of open. Andrew
>>
>> 2009/10/13 andrew cooke <ac...@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.
>
Re: Scala inter-op issue
Posted by andrew cooke <ac...@gmail.com>.
Hi,
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.
Andrew
2009/10/25 Rainer Döbele <do...@esteam.de>:
> 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 <fr...@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 <ac...@gmail.com>
>> wrote:
>> >> Sorry, no - my fault. I was using getRecordData instead of open.
>> Andrew
>> >>
>> >> 2009/10/13 andrew cooke <ac...@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.
>> >
>
Re: Scala inter-op issue
Posted by andrew cooke <ac...@gmail.com>.
Yep - EMPIREDB-60.
Andrew
2009/10/25 Francis De Brabandere <fr...@gmail.com>:
> Do we have a Jira issue for this yet?
>
> On Sun, Oct 25, 2009 at 9:03 PM, Rainer Döbele <do...@esteam.de> wrote:
>> 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 <fr...@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 <ac...@gmail.com>
>>> wrote:
>>> >> Sorry, no - my fault. I was using getRecordData instead of open.
>>> Andrew
>>> >>
>>> >> 2009/10/13 andrew cooke <ac...@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.
>
Re: Scala inter-op issue
Posted by Francis De Brabandere <fr...@gmail.com>.
Do we have a Jira issue for this yet?
On Sun, Oct 25, 2009 at 9:03 PM, Rainer Döbele <do...@esteam.de> wrote:
> 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 <fr...@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 <ac...@gmail.com>
>> wrote:
>> >> Sorry, no - my fault. I was using getRecordData instead of open.
>> Andrew
>> >>
>> >> 2009/10/13 andrew cooke <ac...@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.
re: Scala inter-op issue
Posted by Rainer Döbele <do...@esteam.de>.
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 <fr...@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 <ac...@gmail.com>
> wrote:
> >> Sorry, no - my fault. I was using getRecordData instead of open.
> Andrew
> >>
> >> 2009/10/13 andrew cooke <ac...@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.
> >
Re: Scala inter-op issue [Was: Importing XML]
Posted by andrew cooke <ac...@gmail.com>.
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 <fr...@gmail.com>:
> 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 <ac...@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 <fr...@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 <ac...@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 <fr...@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 <ac...@gmail.com> wrote:
>>>>>> Sorry, no - my fault. I was using getRecordData instead of open. Andrew
>>>>>>
>>>>>> 2009/10/13 andrew cooke <ac...@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.
>
Re: Scala inter-op issue [Was: Importing XML]
Posted by Francis De Brabandere <fr...@gmail.com>.
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 <ac...@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 <fr...@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 <ac...@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 <fr...@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 <ac...@gmail.com> wrote:
>>>>> Sorry, no - my fault. I was using getRecordData instead of open. Andrew
>>>>>
>>>>> 2009/10/13 andrew cooke <ac...@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.
Re: Scala inter-op issue [Was: Importing XML]
Posted by andrew cooke <ac...@gmail.com>.
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 <fr...@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 <ac...@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 <fr...@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 <ac...@gmail.com> wrote:
>>>> Sorry, no - my fault. I was using getRecordData instead of open. Andrew
>>>>
>>>> 2009/10/13 andrew cooke <ac...@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.
>
Re: Scala inter-op issue [Was: Importing XML]
Posted by Francis De Brabandere <fr...@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 <ac...@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 <fr...@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 <ac...@gmail.com> wrote:
>>> Sorry, no - my fault. I was using getRecordData instead of open. Andrew
>>>
>>> 2009/10/13 andrew cooke <ac...@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.