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

Database choices #27

Open
shadowcat-mst opened this issue Apr 14, 2014 · 3 comments
Open

Database choices #27

shadowcat-mst opened this issue Apr 14, 2014 · 3 comments

Comments

@shadowcat-mst
Copy link

Given you're using DBIx::Class anyway, why not use DBIx::Class::Candy to declare the result classes, then DBIx::Class::Migration / DBIx::Class::DeploymentHandler to generate the .sql files?

SQLite would make a great choice for small blogs and for experimenting with the software, and PostgreSQL is going to be a vastly preferred 'real' deployment option to MySQL for lots of people.

Plus ::Candy is so much prettier :D

@bjoernfan
Copy link

I haven't really inspected the code, but what's the reason to generate .sql files? Why not use DBIx::Class::Schema->deploy? (Just sharing what I've used, not saying that it's better than any other solution).

I haven't used ::Candy either, but I'm using deploy here if anybody wants an example.

@shadowcat-mst
Copy link
Author

On Mon, Apr 14, 2014 at 08:33:00AM -0700, Björn Pettersson wrote:

I haven't really inspected the code, but what's the reason to generate .sql files? Why not use DBIx::Class::Schema->deploy? (Just sharing what I've used, not saying that it's better than any other solution).

Because deploy is a one-off deploy - great for development, sure.

However the proposed tools are designed to handle versioning and upgrades too.

The reason to generate .sql files is so (a) people can actually read the
SQL files (b) you can double check the results are sane (c) if you have
any oddities to deal with you can edit them (and the code will use the files).

Plus, the diff files need something to diff against to generate them, and
of course the old version of the schema isn't there anymore unless you ship
a complete git repository with the app :)

Basically, ->deploy was the original one that I wrote - and is still great
for "dump current schema version into the db" - but the more recent stuff
is rather more sophisticated.

(also, I assumed that Schema::Loader meant that you had people who really
really wanted to see SQL, because that's about the only way it makes sense
for a new project that owns the database like PearlBee does :)

Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

@bjoernfan
Copy link

Wow, that was a patient answer! The more you know. Thank you. :)

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

2 participants