Skip to content
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

Multiple dropColumns in one migration #46

Closed
tooshay opened this issue Jun 22, 2018 · 10 comments
Closed

Multiple dropColumns in one migration #46

tooshay opened this issue Jun 22, 2018 · 10 comments

Comments

@tooshay
Copy link

tooshay commented Jun 22, 2018

I'm trying to write a couple of tests for some added functionality to the API and using SQLite for the tests, as CandyAPI seems to be. In the 2018_01_15_120102_add_fields_to_transactions migration there are multiple dropColumns in the same transaction - how did you get that to pass, with SQLite not supporting this behaviour?

@alecritson
Copy link
Contributor

This is the exact issue we found when we wrote tests for our projects that use getcandy, in the next release the migrations should be edited to stop this issue happening.

@Jamiewarb
Copy link
Contributor

Any idea when the next release will drop? Been trying to find an indication but not been fortunate to find one.

@alecritson
Copy link
Contributor

Hey @Jamiewarb, We're looking to get it out of Alpha and into Beta around the end of August.

@Jamiewarb
Copy link
Contributor

Jamiewarb commented Jun 25, 2018

Okay, thanks for letting me know!

We're looking to build a medium scale e-comm project on top of Candy, but not sure if we're able to commit to it at this point, which is unfortunate.

Will you guys be creating a pre-release with these fixes that we can contribute to? If these issues are already being solved, I'd rather not fork and re-solve them myself, but focus effort on outstanding bugs.

I see a dev branch, so would I be right to assume that is the current alpha? Is there a strategy for contributing?

(Sorry that this is likely not the space for it, so please point me to the direction of a better forum if you'd prefer, but just going to ask here for the sake of continuity)

@tooshay
Copy link
Author

tooshay commented Jun 26, 2018

Hey @alecritson, wondered if you had any input on the above? Are people generally forking from Dev? Or Master? I'm noticing some pretty big differences between the two, now that I'm trying to the get the client and API working in our project (i.e. Api directory replaced by Core, etc).

@alecritson
Copy link
Contributor

Sure, so we initially released the real base Alpha version at the end of February, this was just to get it into peoples hands. We didn't want to offer too much support at this point as we knew things were going to be changing pretty drastically and so instead of patching the master branch and doing alpha release updates we kind thought "lets just go for beta" so that's what we're doing.

The current release tag / master is really just how it was when it was first alpha released, the dev branch is constantly in use by us, so we never really told people to go ahead and use the dev branch as it's the bleeding edge of what we're doing before we get it into a proper release system and could potentially contain alot of bugs / new migrations etc as we develop it.

By all means if you want to use it in the dev state then you can include dev-dev in composer, or how I've been doing it is cloning the repo down and adding:

{
   "type": "path",
   "url": "../candy-api",
    "options": {
      "symlink": true
     }
 },

To my composer so you can easily just pull down the changes locally to see whats changed without having to constantly do composer update.

As for contributing we aren't really advertising that as we don't want to overwrite your hard work or work you've put time on, but if it's an obvious bug fix or whatnot then pull requests would always make us smile, but yeah, dev branch is where it's at.

@alecritson
Copy link
Contributor

Oh and as for these types of discussion, we have a slack area but Glenn is away at the moment and I don't have the access to give you guys invites so when he is back I'll put a link here or something.

@tooshay
Copy link
Author

tooshay commented Jun 26, 2018

This is great, @alecritson. Thanks, dude.

@tooshay tooshay closed this as completed Jun 26, 2018
@Jamiewarb
Copy link
Contributor

Jamiewarb commented Jun 26, 2018

Cheers for the reply mate! We'll definitely be getting involved with the Slack when we can, if you guys are cool with that.

I think what we will do for now is fork the dev branch of candy-api, and also fork the candy-client-php repo as well. Then we'll use those in our projects, and bug fix anything we find internally, while also pull-requesting any bug fixes into your getcandy repo's as well.

That should hopefully benefit us both, and allow us to use the dev branch without worrying too much about the changes and fixes you guys are making. Then we can intermittently review your dev branch and merge it into our fork to get your updates and progress as well, and you should hopefully benefit from our bug fixes in return.

If any of that sounds daft, I would totally appreciate the feedback 😅And if not, then you'll have two new contributors :) (Thanks for the continued patience with us! :D)

@alecritson
Copy link
Contributor

Hey @tooshay @Jamiewarb

Glenn is back off holiday now and I have access to invite you guys to the slack channel if you are interested. Just shoot me an email at alec@neondigital.co.uk and I will get you the links.

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

No branches or pull requests

3 participants