search

calebmer / accelerate

Accelerate back and forth through time for your database or other in-place systems
MIT License
5 stars 0 forks source link

Rust rewrite #2

Closed svmnotn closed 8 years ago

svmnotn commented 9 years ago

No more runtimes

calebmer commented 8 years ago

Those are some nice commit messages 😊

Ok, did some code reviewings, the method for debugging, println!, is that temporary? Also, where are the tests?

svmnotn commented 8 years ago

The main method bit are the tests ;) if you read the whole of the commit msg you would know.

calebmer commented 8 years ago

I know, I just really don't like it 😊

I need formal tests to merge so we can determine when backwards compatibility is broken and set up a CI service.

svmnotn commented 8 years ago

I'll do them when I learn how...

svmnotn commented 8 years ago

learned how to do tests in Rust :) for informational purposes the command is cargo test

calebmer commented 8 years ago

What's the progress? Do we need to talk?

calebmer commented 8 years ago

Nice! What's left to do:

calebmer commented 8 years ago

Also, is there anything I need to doc or fix docs for? If so just comment the areas.

svmnotn commented 8 years ago

I would like you to go over the code and add doc for anything that does not have it, also some reorganizing would be nice.

calebmer commented 8 years ago

Sorry for not responding for a while, school takes up too much time…

Did a code review, it's looking great! One thing I noticed, PostgreSQL support hasn't been done yet, but that shouldn't be too hard. I'll write docs, but it might be a bit (school makes it harder to have writing time & coding time).

I talked to someone the other day about database migrations and found out a couple of directions accelerate should probably take. There are two actionable things I derived, both of which have to do with better support for a git multi-developer environment, and both of which you should probably weigh in on. I should be able to help develop these things once we merge in what we have currently (it gets kinda crazy working on a pr to a pr :blush:). Here are those things:

  1. Instead of doing 001 -> 002 for sorting motions, we should use a timestamp with seconds precision. This should give enough entropy that if two developers both open a PR with two new motions, their versions shouldn't collide.
  2. State should probably not be represented as a number. Again let's use the example of two developers with two PRs with new motions—after they both merge in one of them will have a new motion in the middle of their motions list and accelerate will try to reapply some motions as the number and order of motions changed. We should implement a method to accommodate the use case when the number of motions and the order of the motions changes. Not exactly sure how we do this. Maybe a list of added motions we can diff against?