Switch from SQLAlchemy to PonyORM

NiklasRosenstein commented 6 years ago

I think SQLAlchemy is cumbersome to work with. I've been using a lot of PonyORM recently and it feels way more inuitive and it makes it easier to maintain models. When set up correctly, the PonyORM models should be able to use the same SQL schema directly, so no migration process is necessary.

Thoughts on this are welcome, of course.

gsantner commented 6 years ago

have to admit, I may touch many parts probably, but if possible not database :D

NiklasRosenstein commented 6 years ago

Haha, don't worry. But if you like, you can make a few tests using the issue/43-switch-to-ponyorm branch.

gsantner commented 6 years ago

merge conflict from master

NiklasRosenstein commented 6 years ago

Don't merge it, just check it out: git checkout issue/43-switch-to-ponyorm. And don't forget installing PonyORM: pip install -r requirements.txt

gsantner commented 6 years ago

for build in select(x for x in Build if x.status == Build.Status_Queued): maybe something other than x make it better readable, same for others.
app.logger.info('Build {}#{} started.'.format(build.repo.name, build.num)) - maybe fstrings

On python's sqlite frameworks or PonyORM I can't give any feedback. I used sql/ite in many other langs and frameworks, but on python I'm not aware of all the frameworks that exist.

what I would seek for from database design - I see it's currently thought to only support one SSH key. Maybe prepare the structure to get ready for a per-project-basis-ssh key.

e.g. gitea only does allow to assign one SSH key once - doesnt matter if repo-deploy-key or user key. If I want to supply the key to just my website, I can't use it anymore somewhere else, unless I give it full permission over my users all repos. which one does not want for just deploy key targeted at specific project.

too, ssh keys usually are encrypted by a password, which too no way to store that yet

overall: would go for that what's easiest on eyes and use (as in amount&quality of fluxci code). this makes it easier to get into project - and this is not targeted to be 100% performant. unless it pulls in like 10 dependencies.

gsantner commented 6 years ago

btw, waiting for merge before going on with ci-file stuff. don't wanna put 50% time in merging :D.

NiklasRosenstein commented 6 years ago

I actually like single-character variables in tight comprehensions, though x is an arguable choice. :'-)

F-strings are only available since Python 3.6. Living on the edge may be nice for development, but it's not as good if you actually want your stuff to be deployed. If you don't containerize, you may only have Python 3.4 or 3.5 available.

what I would seek for from database design - I see it's currently thought to only support one SSH key. Maybe prepare the structure to get ready for a per-project-basis-ssh key.

I can not quite follow you. Do you mean that you should be able to configure an SSH keypair per project that Flux should use when it clones a project?

btw, waiting for merge before going on with ci-file stuff. don't wanna put 50% time in merging :D.

Won't be too long. :)

gsantner commented 6 years ago

I can not quite follow you. Do you mean that you should be able to configure an SSH keypair per project that Flux should use when it clones a project?

yes. plus in all cases it would be good to have option to optinally enter ssh id password.

NiklasRosenstein / flux-ci

Switch from SQLAlchemy to PonyORM #43