sql_restore functionality of ocr

[Duke-Jones]

Full functionality must be tested.

Known problems:

• adding of unknown commodities does'nt work yet

[MRmP]

I've looked into ImportCommodities and it seems to be fairly simple to import unknown commodities. Question 1) Do we want to send the unknown commodity to eddb?

Question 2) Do OCR currently support to identify which category a commodity belongs to?

Question 3) Is ID in tbCategory and in tbCommodity increased automatically or do we need to set a key manually. In either case, what happens if a manually added comodity is added, then a resync with EDDB suddenly has a new commodity with that Id, or is the Id not copied from eddb? (I realize i can trace back the code to answer this myself)

Question 3) In cases where we do not have any information, such as "average_price" would null or -1 be sufficient?

[Duke-Jones]

I thought about to use ImportCommodityLocalizations() instead of ImportCommodities() because ImportCommodityLocalizations() takes more care on the current language.

I took ImportCommodityLocalizations() for importing the english data from EDDB without any localization (if I remember right).

1. could be interesting for us to collect the names of commidities of differnet languages for support a growing amount of translations. I assume EDDN ignores unknown commodities. As RN already sends the data it seems simpler for us send send it without imlementing a additional filter for unknown commodities. But it must depend on the setting "Post data to EDDN on import".
2. No. But as a future feature we should think about it.
3. no it's no autoincrement. Self added commodities/stations/systems should become the next free negative number. If we get it later as a known commodity/station/system (text comparision positive and not yet existing id in our database) we replace the self added data with the more complete data from the eddn with it's id. The old negative id is then no longer existing. I also have implemented the _org tables of stations and systems to hold the original data if the user make changes on e. g. system. If there comes the same station with a newer "changed at" time it's for the moment so that the own data will be rejected if it is older. Or if the own data is still newer than new eddn data the eddn data replaces it's on predecessor in the "tb..._org".
4. Im not sure for the moment. But feeling tells me to take them as "null". But I'm not sure if there are collisions in the current code.

All points can be discussed :-)

[MRmP]

1) Collecting different language is not that relevant for the general usercase. I don't think many players switches languages. Though If we are to build/update a database such as EDDB it will absolutely gain from different languages, Though a mapped language to one commodity entity would probably be better, ie. "Sugar" and "Sucre" is the same commodity and all metadata such as price would be the same, and when searched for "Surcre" we would also need to get price information from Sugar and.. Zucker.

2) Lets file this as a feature request, could be nice if we want to collect more of our own data and not relate to eddb in the future

3) got it, I see you have the "currentSelfCreatedIndex" ready for use.

4) Null is the proper way.

5) I see we can reuse the ImportCommodityLocalizations, I suggest we split it up so either a edcommodities or string:filename (Existing) can use the same code

[Duke-Jones]

1) it is - I for myself play in german and it was one of my first needs to make a version which was usable in different languages of elite. But it is also not so complicated as you think or rather implemented yet.

Have a look on the localization tables (green area on the right in MySQL Workbench). There are the translation for each commodity. On switching the language the localized name (e. g. loccommodity in tbCommodities) will be reset with the correct languagedependent string. For all displays we simply must use the "loc...." string. For importing: If you get a priceinformation, so the import function must search for the commodity where the english originalname OR the localized name equals to the import name - voilá, there you have the commodity, independent from the language your elite runs. Only if we have a (e. g. a german) unknown commodity, we can import this as a new commodity. The user must have a option to reassign the new name to the english orginal commodity, if it's already in the eddb exists. If it's really new, the user can also add the english originalname and first time the commodity comes from eddb a automatic routine can reset to negative id to the EDDB id. No big thing...

2) ok

4) ok

5) ok, but please take account to my remark on 1.

[Duke-Jones]

example:

Three times fish in different languages with only one selection:

select * from tbcommoditylocalization L, tbCommodityData D where L.Commodity_ID = D.commodity_id and L.locname = "Fish";

select * from tbcommoditylocalization L, tbCommodityData D where L.Commodity_ID = D.commodity_id and L.locname = "Fisch";

select * from tbcommoditylocalization L, tbCommodityData D where L.Commodity_ID = D.commodity_id and L.locname = "Poisson";

the same logic we can use to add new prices from different languages for a special commodity. The language is nonsignificant.

SQL is powerful :-)

[Duke-Jones]

btw: ist it possible for you to change the lables of the issues ? e.g. add the "in progress" label ?

Edit: No, I think you can not. Do you want to work on this package ? Then I will set the "in progress" label.

[MRmP]

no, I don't seem to be able to do anything except comments

[MRmP]

Yes please, sign me up on this one :)

[MRmP]

Also doing some refactoring in this package, moving OCR out of Form1 and root directory into Ocr Directory

[Duke-Jones]

ok. If you have questions about the things I've already done - never be afraid to ask :-)

[Duke-Jones]

btw: seems you're do'in #94, too

:-) :+1:

[Duke-Jones]

I added a quickfix (dff2e12430263c49b55c7acf4c4e26ce9d19a8ab) I hope it does not collide with your work.

[MRmP]

doesnt seem to collide, not been able to put in much work as i'd like lately, hopefully should be back on the horse within a few days