SQLAlchemy models, refactor helpers calls

[amercader]

fixes #33

---

@roll This is ready to review.

There are two main things:

1. Obviously set up SQLAlchemy models and replace dataset calls with SA equivalents for interaction with the DB
2. I didn't like how in some places, specially the tasks and the tests we were interacting directly with the DB rather than going through helpers. In most cases plugins or tasks should not need to worry about SA syntax (similarly to how dataset abstracted some of this complexity) and helpers should be the main API to interact with jobs and other future objects. Because tasks use a different session, this implies that sometimes you need to explicitly pass a session to the helper methods. I think the benefits of conceptually separating the interaction with the DB outweigh this minor inconvenience.

Let me know what you think

[roll]

@amercader
A few thoughts:

• one things which is bothering me long time is how we run celery tasks - we do it in plugins.github.blueprint and helpers.create - in my opinion it's pretty inconsistent (because it's different logical layers). I think we need to sync it e.g. moving second one to blueprints.api (so all task runs inside web handlers)
• I don't see anything criminal in exposing SA interface to plugins because it's still our internal code. But I see a good benefit of encapsulating all db related code in models (commonly used data layer encapsulation). WDYT about it? Getting rid of the most of helpers moving db-related code as static methods of models.Job - I suppose it's pretty common pattern. SA specifics could be still hidden here. I suppose our helpers is getting messy already. If we will move code this way we will be having all db-job related code inside e.g. models.job module.

[amercader]

@roll +1 on the first point, see 904ce90

On moving DB logic to models, I'm also happy to do that. I'm not so keen on static methods on classes though, specially on the actual SQLAlchemy models. I think plugins should just pass and get dicts around and not actual SA objects. What about keeping the helpers as they are but moving them to the models.job module as you suggested?:

• helpers.create_job() -> models.job.create()
• helpers.update_job() -> models.job.update()
• helpers.get_job() -> models.job.get()
• helpers.get_jobs() -> models.job.find()
• helpers.get_job_ids() -> models.job.get_ids()

Usage:

from goodtablesio import models

job = models.job.create(params)

or this, whatever we prefer:

job = models.job.create(**params)

[roll]

@amercader
I'd be happy to have it in one place. Static methods or function or whatever - just not so important for me than concept of highly cohesive modules. So +1 with any you prefer.

[amercader]

@roll please have a look

I've moved all db related methods to models.job. I think this is much nicer, thanks for your feedback.

While I was at it I renamed Job.job_id to Job.id as it makes more sense. I also fixed some inconsistencies in the models definitions / migrations.

[roll]

👍