8000 Add file import/export by Viggor · Pull Request #1 · initOS/connector-interfaces · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add file import/export #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 9 commits into
base: 8.0-connector_flow
Choose a base branch
from

Conversation

Viggor
Copy link
@Viggor Viggor commented Jun 17, 2015

Module to handle file transfert

@OSguard
Copy link
OSguard commented Jun 17, 2015

Do you want to make the first draft or need some input?

@Viggor
Copy link
Author
Viggor commented Jun 17, 2015

I will make a first draft.

@Viggor
Copy link
Author
Viggor commented Jun 17, 2015

After some investigation i'm not sure how to link our modules. My module just create an ir.attachment from a remote file or a file from an ir.attachment. So do you think we should separate the transfert task from the flow and start the flow from a ir.attachment?

@OSguard
Copy link
OSguard commented Jun 17, 2015

the first task in a flow is to download it and store it in ir.attachment and the the next steps runs
So i guess you just need to refactor that it will inherit from the 'AbstractTask' object and implement the run() method

@Viggor
Copy link
Author
Viggor commented Jun 17, 2015

There is already the same logic, i have an abstract task with a run method.
I really think the treatment and the transfert tasks, in some case the treatment is not needed (for example export of sale order report) so we don't want to depend from Connector.
The best way is to manage treatment and transfert separatly, so your flow will get an ir.attachment create by my module (for import case) or your module will create an ir.attachment which my module will export (for export case).
To do this we need to remove the export/import parts from your module, change the binary field in the wizard to a many2one on ir.attachment (for import) and create an ir.attachment which will be handle by my module instead of sending it to FTP.

What do you think about that?

Maybe we can ask @guewen or @sebastienbeau for their opinion to have the better solution.

@OSguard
Copy link
OSguard commented Jun 17, 2015

i need to discuss this with @codingforfun for this details
why you don't want to depend on Connector? In my opinion it make sense no one to force something to use what he don't need. So the basic problems working with any third remote connection are:

  1. being temporary not available
  2. slow connection speed
    So connector solves this two without any mayor disadvantage.
    What is the reason we should take additional effort to support a non-connector as well?

@codingforfun
Copy link

I had a deeper look into your code. My impression is that our approaches are at some points very similar but focussed on somewhat different problems we try to solve.

If I've understood your approach correctly, it seams to me you are mainly implementing some very cool approach for automatic file syncing for Odoo like a dropbox folder on a local machine.

Our focus is on automated processing of information by a chain of various processing step. Import/Export is just a single aspect of this. One of our main goals is to make every step robust, traceable and repeatable in case of error. That is why we build on top of the connector.

It's right that FTP is just one special kind of task in our framework, so it would make sense to refactor this to split up into a core framework and helper tasks, but since your approach brings it's own kind of task framework I'm not sure what could be a good way to unite with our approach.

I think it's not possible to just plug both approaches together. Maybe we could reuse some of the ideas. I think the meta data approach for ir.attachment and the idea of remote sync locations makes sense from a user perspective. Maybe you could use our task framework to implement your approach of remote file sync for ir.attachment.

@Viggor
Copy link
Author
Viggor commented Jun 18, 2015

Thanks for the comment, i will discuss with my coworker about your suggestion and I will tell what we can do about it.

@sebastienbeau
Copy link

Hi, I think too, that our both module do not solve the same problem.
Your module is here to process a flow a data, and our is just a small step of synchronization with external file system (ftp, sftp, filestore, ...)

Plugin both is maybe not an easy task but I think it's worth
I think we have different concept here that worth:

  • Concept of 'location' that avoid to duplicate a ftp/sftp/... config in different task (I can have one FTP, and have 3 export task and 2 import task).
    Concept of "syncronisation task" which is just some extra params of configuration and make easy the possibility to send easily file (ftp, sftp...) without big dependency.

Regarding the dependency of connector or not I would like to have the opinion of @guewen
Indeed for the French Carrier "la poste" we need to import/export some file on a FTP (https://github.com/akretion/carrier-delivery-colipostefr, the project can not be merged yet in OCA due to this issue). I can for sure re-developpe in this module (and also in other carrier) the code for sending/getting the ftp but I would really prefer to have a small brick that do the job for me. Having only one way to manage all file-synchronisation is I think a good idea to simplify the training and the maintenance for the user. On my side, I am not against depending temporary of connector as in the futur we will probably split the connector in several sub-project (like extracting the queue management), but I really not sur that we need to add to the delivery_carrier_colipostefr the depedency on connector flow for sending the EDI file.

Regarding the French carrier, the export is a simple csv EDI file that reprensent a batch of picking and the import is an SQL request that update a huge table of records.

@Viggor will try to propose a POC of how we can connect both system, so we can start thinking of the impact of merging both project.

What do you think?

@Viggor
Copy link
Author
Viggor commented Jun 24, 2015

I've make a first POC for our modules integration. It works with well with your ftp export example module.
Tell me what do you think about it and if we continue on this way.

@codingforfun
Copy link

Ok. Interesting. Thanks. I will try to have a deeper look as soon as possible and discuss with @OSguard


def _get_method(self):
res = []
for cls in itersubclasses(AbstractTask):
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will load classes of uninstalled addon as well. In connector we also check if the addons from where the class comes is installed or not.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now these class are push away of the code evaluation. Thanks to point it.

@OSguard
Copy link
OSguard commented Jul 17, 2015

a short update, we hope to provide a feedback from our site next week (sorry this was delayed two weeks). Hope we can make it befor the holidays

@Viggor
Copy link
Author
Viggor commented Jul 17, 2015

Ok no problem thanks!

@bealdav
Copy link
bealdav commented Feb 25, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
0