Why use Moose? A PostgreSQL perspective.

http://ledgersmbdev.blogspot.com/2012/07/why-moose-postgresql.html

by einhverfr • 14 years ago

60 10 14 years ago

ledgersmbdev.blogspot.com

Moose is not really an ORM. You would be better off using an ORM like Rose::DB::Object which can help you with type constraints.

hifoo• 14 years ago

Moose was not described as an ORM just an object system. PostgreSQL was used as an example of a system with rich types and constraints.

einhverfr2• 14 years ago

We are stored procedure-centric. An ORM wouldn't help us. What Moose brings is an ability to bring the sort of rich type constraints we are used to doing in-db into the application level.

dhoss• 14 years ago

This is pretty neat. I'm always in favor of multiple levels of data validation and your use of Moose is good in this sense. Check out Data::Manager as well (or Data::Verifier if you just want the validation goodness), it uses Moose's type constraint system to validate your data.

avar• 14 years ago

I have lots of cronjobs that use the Moose type system to validate data before it gets inserted into either a MySQL row or an ElasticSearch document.

It's a really nice method and has caught a lot of errors in the data those jobs are slurping up before they've impacted production.

It also allows you to do very complex type checking that you wouldn't be able to do in the native type systems of most languages (e.g. with MooseX::Types::Structured), like checking not only whether something is a hash, but it can only have these keys, and each of those keys have to match some constraint.

Obviously you can write custom code to do all that, but offloading it to the type system is so much nicer, and makes it trivial to share those checks between different modules.

It also makes it easy to selectively disable checks, e.g. if you have a large blob of data you're inserting into permanent storage in a cronjob you might like to to extensive validation of it, but you might not want to incur that validation cost on every retrieval in the system that consumes that data.

stonnyfrogs• 14 years ago

Moose is easily the biggest administrative pain in the ass of all time. Any::Moose just makes it work. If you can get away with pure-perl Mouse, it's okay -- but once you dive into Moose... I hope you handle your own hosting.

logie• 14 years ago

There is also Moo - https://metacpan.org/module/Moo

einhverfr2• 14 years ago

Typically LedgerSMB is hosted by people who know what they are doing regarding the software, or it is self-hosted on-premises by the customer. I know of a few hosting providers. One charges $20/month for the service.

We are running on PostgreSQL which removes most of the options for $3/month hosting anyway.

But we already have dependencies that require Moose and therefore there isn't much point in avoiding it.

draegtun• 14 years ago

I have never ran into any of the issues that you had with Moose. I've been using Moose since 2007 and its always been seamless to install, manage and use.

To load Moose on a vanilla perl only takes a couple of minutes and only uses 22 other modules: http://news.ycombinator.com/item?id=4042637

btilly• 14 years ago

Moose is nice and full-featured, but slow. So Mouse was created to be similar to Moose, except a bit more limited and faster. However Mouse still has a ton of features and complexity, so Moo was written to be just the most used 60% of Moose, implemented as simply as possible.

Different Perl libraries have chosen to use different ones. So in a large Perl project that uses a bunch of standard libraries you can easily wind up pulling in all three. Thus the common desire to produce something lightweight and fast has created bloat and slowness.

Why use Moose? A PostgreSQL perspective.

Related Stories