Migrations seems not to be sane

[ElectricMaxxx]

hi,

i am followed the bundle with the purpose to see other connections to oxid than my own, that we created the last weeks. So i wanted to have a look into the migration. At the first view the mapping on the database cols seems to be very cool and easy, but it isn't oxid has got a lot of logic in their objects, that manipulates them. So you can't see the database tables as the entities you can work with. I will give you two examples:

Price calculation

You won't ever see the value of OXPRICE in the frontend. The value is manipulated depending on several shop settings (net/brut view, payment rules)

Translated text - Title of a product

Your mapping will work for shops with one base language. Oxid generates the translations by adding an extra col to the database table like title_1, title_2, ... So you won't be able to map the right col in your entity for the migration.

I would see two different solutions. Both base on the situation, that you need Oxid the oxid logic (means the shop it self) in between.

1. Create a SDK
   That means the Connector would just define some interfaces and services to to update the Ongr values. So the oxid shop devs would create its own module with its own logic to connect to Ongr. They would just extend the oxArticle 's save()/delete() method and create their own mapping to the document you persist. Mostly the devs would same methods/mechanism that oxid is calling when creating the values for the frontend.
2. Implementing that Connector and bootstrapping parts of the shop ...
   ... to call its own logic while fetching the values from the objects.

Even when i would mean to create an other package/module, i would prefere the first solution.

[saimaz]

Thanks for the feedback @ElectricMaxxx this will help as a lot!

Talking about prices, I'm afraid we do not support user price lists which OXID has. But it's only the question of time once it will be supported. We are working on it.

To understand fully multi-language support we still missing documentation for this. But it's on the way, and soon it will be available. IMO to use entities it's fine. Let me explain in more detail. We suggest to use different sf2 environment for different language. So this means that we have different cache for each env. We created event listener that binds when doctrine creates cache and changes to the language id in annotation for right column selection. Sounds complicated but it works quite good. Soon there will be a box prepared with working OXID sync. I'll let you know when it will appear.