-
Notifications
You must be signed in to change notification settings - Fork 580
Database support
Mojo::Pg, Mojo::SQLite, perhaps others... Not using an ORM... There's so many things that are better than what's below now, IMHO.
Mojolicious is a fast, lightweight framework without any dependencies to further modules except the core modules of your Perl distribution. Therefore it doesn't include any database storage methods except those which are inside the core modules already like dbfile. If you look for a more complex database engine you should keep the simplicity in mind. Pulling DBIx::Class for database operation inside your webapps is totally fine with Mojolicious, however, it has a pretty decent number of modules it depends on. If that's not an issue for you that's totally fine, go ahead. If you need to keep an eye on your dependencies and your environment (like shared webspaces) you should choose a different option.
ORLite is a small OR mapper based on SQLite, see the short introduction in this wiki.
CouchDB is a nice option as Mojolicious is able to work with JSON well. Check out the documentation inside this wiki about examples of CouchDB and Mojolicious.
Membase is a NoSQL database which basically is a memcache daemon with a persistent data layer. It supports clustering and replication. The membase database uses the memcache protocol (binary and ascii) as API. Any memcache client will work. The feature set is limited so far.
Redis is another NoSQL database which plays well with light frameworks. A pure Perl client is provided, too.
http://fallabs.com/kyotocabinet/ http://fallabs.com/kyototycoon/
Kyoto Cabinet and its database server Kyoto Tycoon may also be viable NoSQL databases. While there are no Perl bindings for the latter yet its RESTful HTTP interface can be easily accessed using Mojo.
DBIx::Simple in combination with SQL::Abstract is a simple but powerful alternative of a full blown ORM like DBIx::Class.
DBIx::Simple has only one optional dependency, except DBI and the database driver you use - Object::Accessor. It provides per-object (rather than per-class) accessors. Of course you can ignore it if you do not use this feature. Note also that Object::Accessor is part of the core Perl distribution since version 5.10.0.
Although SQL::Abstract looks like having much more dependencies, they are needed only during testing, so you can safely use the module with your application in a shared(hostile) environment. Just unpack it in your lib
directory. And you can always use cpanm of course.
You can build a Mojolicious plugin and use it in your application. The MYDLjE CMS (https://github.com/kberov/MYDLjE) has a pretty good example. See https://github.com/kberov/MYDLjE/blob/master/perl/lib/MYDLjE/Plugin/DBIx.pm and https://github.com/kberov/MYDLjE/blob/master/perl/lib/MYDLjE/M.pm.
DBIx::Custom is light-weight DBI wrapper like DBIx::Simple, but more flexible.
# Connect
my $dbi = DBIx::Custom->connect(dsn => "dbi:SQLite:dbname=$database");
# Insert
$dbi->insert({title => 'Perl', author => 'Ken'}, table => 'book');
# Update
$dbi->update({title => 'Perl'}, table => 'book', where => {id => 5});
# Delete
$dbi->delete(table => 'book', where => {author => 'Ken'});
# Select
my $result = $dbi->select(table => 'book', where => {author => 'Ken'});
my $rows = $result->all;
See DBIx::Custom on CPAN and DBIx::Custom Documents
These examples were previously used but have either fallen behind the state of the art or have become unreliable or non-functional.
An example of DBIx::Class usage in both full and lite apps: