Skip to content
This repository has been archived by the owner on May 10, 2023. It is now read-only.

Purge open Issues and Pull Requests #74

Open
ludovic-gasc opened this issue Nov 30, 2014 · 5 comments
Open

Purge open Issues and Pull Requests #74

ludovic-gasc opened this issue Nov 30, 2014 · 5 comments

Comments

@ludovic-gasc
Copy link

Hi,

This tool is great, at least better than the ruby equivalent (mysql2pgsql), but I had some issues during a migration that was already fixed on other forkes, and sometimes, resolved the same bug in several forkes.

For example, the empty SQL error:

  1. https://github.com/philipsoutham/py-mysql2pgsql/pull/69/files
  2. https://github.com/clevertension/py-mysql2pgsql/commit/9f7bcb15198cb1a72970de85a58903056a57b20c

Do you need some help to close and merge interesting things to prepare a new release ?
I understand that you don't have time anymore to work on this project, I can help you, if you want.

Regards.

@ludovic-gasc
Copy link
Author

Ping ?

@kworr
Copy link
Collaborator

kworr commented Dec 7, 2014

Sorry, I'm kinda lazy guy... I'm not the project owner so I have no access to pypi. And sometimes I need some time to read docs and understand what's going on. I'm also a BSD guy so I prefer to not patch anything until the patch is final and tested as it's better not to break things than bring new functionality in. After all I'm not the owner.

For example I don't like both patches that you mentioned. First one adds one code block and tests only for the empty string. The second one has better approach but why it's checked after the cursor is created? I.e. moving the check to the beginning of the function looks better to me.

If you really want to help - try making travis work. It was working, then it was broken and there are no willing victims to fix that.

Another good task is to revamp data processing when working with the database. Right now everything is converted to SQL requests (strings) and then fed to the server. The good way of doing that is making source read tuples, create prepared statement for submission and optionally add filter to fix field types. This will greatly speed up the whole process.

And probably yes, we need to mark a milestone as a last release was too long ago, I just wasn't too sure about the commits as I personally can't test everything thoroughly (thus I mentioned trevis at first place).

Thanks for pinging me. I need to be pinged... :)

@ludovic-gasc
Copy link
Author

Hi,

First, thank you @kworr to answer me :-)
If I understand correctly, @philipsoutham gives you admin access for this repository, but not on PyPI ?
The activity of @philipsoutham on Github seems to show that now he's using Go instead of Python, maybe we could give us full access to release new versions of py-mysql2pgsql ?

About Travis, I can definitely help, but I need to give me admin access on py-mysql2pgsql repository and Travis. Is it possible to give me ?

The roadmap I propose:

  1. Fix Travis
  2. Merge interesting Pull Requests and add missing tests, because: First, it will show that this project is again alive for potential contributors. Second, theses Pull Requests represent real world problems you can have with py-mysql2pgsql. To be the referent tool for MySQL to PostgreSQL migrations, we need to handle that. Personnally, I use py-mysql2pgsql instead of mysql2pgsql ruby version, because I have issues with my database migration.
  3. Release a new version with theses improvements, to be usable right now.
  4. Change internal architecture as you propose, we could also be compatible with Python 3. For this part, you seems to have a better vision than me.

What do you think for this roadmap ?

@dmr
Copy link

dmr commented Aug 14, 2015

Did anything happen here since?

Do I read correctly that I should use the git version?

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

No branches or pull requests

4 participants