#43 ExtraInfo missing in XML Export&Import

[Matthias Ihmig]

Manually added fields (ExtraInfo) are neither exported to XML nor Imported.

As this helps in fixing and migrating in potential corruption situations, as well as for merging databases and backing it up, this should work!

If an ExtraInfo field does not exist, it should be created first, so that no data is lost on XML import.

Matthias

[Bro]

Logged In: YES
user_id=840074
Originator: NO

CVS is updated, and extra info fields are now exported and imported correctly.
The fields are not added automatically. Neither does an error occur.
This should be worked on some more.

Bro

[Matthias Ihmig]

Logged In: YES
user_id=921651
Originator: YES

In CVS, extrainfo field are now somewhat imported, but they do not map correctly to existing info fields or wrong-order fields in the target DB, so I re-opened this bug report.

Howto reproduce:
1) Create a new DB, with two extra info fields "ex1" and ex2", and fill with a few movies and some data in the additional info & extra info fields
2) Export to XML
3) Create a new DB, create three extra info fields "oldexinfo1", "ex1", "ex2"
4) Import XML
-> Bug: The extra info fields from imported movies are mapped to the wrong entries.

This is very important, because importing/exporting to xml is usually used to merge 2 existing databases, and most probably, the have preexisting extra info fields.

So, I consider a (case-insensitive) name mapping very important.

This will then also allow to create non-existing extra-info fields resp. re-use existing ones.

Thanks,

Matthias

[Bro]

Logged In: YES
user_id=840074
Originator: NO

umm...
For this to work I guess the database must have the same fields (field count and name) as those in the exported XML file, which is kind of stupid.
The problem here is that the fields and values are saved in ArrayList so the only way to know which goes with which is the index.
When castor adds the values it's not possible to know the index, as only the values are sent to the method as argument.

I guess it would be better to store the extra info names and values in a HashMap so that both the key and value are stored together in the XML file.
To make this non-hacky it's best to remove the ArrayList completely from the Additional Info, but this requires some extensive changes in other classes as well.

What do you think?
I can do it, but I hope you're prepared for some more beta testing (oh what a happy day).

[Matthias Ihmig]

Logged In: YES
user_id=921651
Originator: YES

> For this to work I guess the database must have the same fields (field
> count and name) as those in the exported XML file, which is kind of
> stupid.
> The problem here is that the fields and values are saved in ArrayList so
> the only way to know which goes with which is the index.
> When castor adds the values it's not possible to know the index, as only
> the values are sent to the method as argument.

I don't know exactly how castor works and if it is possible to do this "mapping" with castor, but if it is not, I think we need an extra routine to handle export/import of Extra Fields.

> I guess it would be better to store the extra info names and values in a
> HashMap so that both the key and value are stored together in the XML
> file.
> To make this non-hacky it's best to remove the ArrayList completely from
> the Additional Info, but this requires some extensive changes in other
> classes as well.

A hash map would be a possibility. But is this really necessary?
Not sure how exactly castor works, but if we don't just use the dump/load functions,
but do our own mapping just for Extra Info and just for XML, we don't need to change
any DB formats & interfaces, and just change the XML importer.

> What do you think?
> I can do it, but I hope you're prepared for some more beta testing (oh
> what a happy day).

Well, as the rest of the DB is indexbased and not hash based, just changing ExtraInfo is probably a little confusing.

When merging Databases, we can limit XMM to only import(=merge) xml (no mysql, no hsql, ...)
When we do that, we could probably do it in the following way:
1) Keep xml export functions (i.e. export index-based)
2) Keep xml format (we now DO have all the necessary entries in there)
3) Change/rewrite the Import XML function:
- keep the way on how to import General&AddInfo fields
- import XML (at least ExtraInfo) to a temporary db or temporary array
to be able to work with it (get index/fieldnames etc)
and compare field names, add new ExtraInfo fields to existing DB, move the data, ...

Do you think 3) is reasonable&doable with or without castor?

Thanks,

Matthias

[Bro]

Logged In: YES
user_id=840074
Originator: NO

Nr. 3 will definitely work, but I'll have to try some more and see if I find a way without changing extra into HashMap.

[Matthias Ihmig]

Logged In: YES
user_id=921651
Originator: YES

Just to clarify things: 1+2+3 are not meant as "either" but as "and". But I think you understood what I tried to say :-)

Well, I'd feel better if we (you ;-) ) could find a possibility to keep the db structure and write the import function "manually".

I hope to find some time to test the new release soon!

Thanks,

Matthias

[Bro]

Logged In: YES
user_id=840074
Originator: NO

I believe this has been fixed.