Pawel Sztromwasser wrote:
>>> The second thing is transferring wizzzards. In our Base1 database those
>>> with /formatType=reportermap/, have column and row numbers in /mapping/
>>> property proceeded by /_r_x /and/ _r_y/ respectively, not by /numCol/
>>> and /numRow/ as WizzzardTransfer class expects. That causes the
>>> ReporterMapImporter plugin configuration to fail. I don't know if the
>>> mapping format has changed, but if the old one is still in use, the
>>> migration could support it.
>>>
>> BASE 2 supports the same mappings as BASE 1 (and some more). I think it
>> should be backwards slashes, eg. \_r_x\, etc. I am not sure what you
>> mean with that the WizzzardTransfer expects \numCol\. The migration
>> doesn't care about the mapping expressions. It should transfer them
>> exactly as they are. Please post any error messages/stack traces, etc.
>>
>>
>>
>
> I am sorry, the backslashes were added by Thunderbird when changing from
> italic to text format.
> The wizzard transfer works like this (when comes to mapping):
> 1) it parses mapping string from Base1 database using regular expression
> looking for (key:value) pairs separated by comma (example part of a
> mapping string:
> _r_block:1,_r_x:\"Column"\,_r_y:\"Row"\,reporterId:\"Probe_ID"\, ...)
> 2) it puts the (key,value) pairs into HashMap
> 3) and uses this map when configuring import plugin. When getting those
> values, it looks for certain keys ('numCol' and 'numRow' are among them,
> explicitly coded around lines 130 and 140 in WizzzardTransfer.java).
> When there is no value in HashMap it returns null, so null is passed to
> plugin configuration. Then it complains:
Hmm... it seems like the code transfering 'reportermap' file formats is
not correctly coded. It doesn't look for any coordinates mappings at
all. The 'numCol' and 'numRow' you are referring to are part of the
'result' file formats, not 'reportermap' file formats.
On the good side is that this doesn't stop the migration. The only
problem is that the file formats for reporter maps are not transfered.
> My changes should work with MySql with no problems, but they are not
> 'nice-coded'.
> Failing method PreparedStatement.getParameterMetaData is used in three
> places in code :
> - run() : Transfer.java
> - runUnbatched() : Transfer.java
> - run() : SampleTissueTransfer.java
> Each time only for getting parameterCount from statement query (number
> of question marks in query in migration-queries.sql file). Only two
> queries have this value != 2 and none of the classes using those queries
> uses methods mentioned above. So what I did was just commenting this:
> //int parameters = ps.getParameterMetaData().getParameterCount();
> and adding:
> int parameters = 2;
> in those methods. Not very nice-coded, but little change that makes it
> work. I am sure you will find better way to code that. I did not change
> the number of question marks in none of the queries so it should work
> with MySql as well.
We will not do anything about the problem. Since Postgres has fixed it
in a later version our policy is that users should upgrade. The
hard-coded approach is not solid enough to make it into the main
distribution.
/Nicklas
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
The BASE general discussion mailing list
basedb-users@lists.sourceforge.net
unsubscribe: send a mail with subject "unsubscribe" to
[EMAIL PROTECTED]
