UR::Object Transactional, queryable, process-independent entities
Download

UR::Object Ranking & Summary

UR::Object Tags

entities transactional process-independent entities transactional entities queryable entities process-independent

UR::Object Description

Transactional, queryable, process-independent entities UR::Objects are queryable, transactional, representations of entities, built to maintain separation between the physical reference in a program, and the logical entity the reference represents, using a well-defined interface.UR uses that separation to automatically handle I/O. It provides a query API, and manages the difference between the state of entities in the application, and their state in external persistance systems. It aims to do so transparently, keeping I/O logic orthogonally to "business logic", and hopefully making code around I/O unnecessary to write at all for most programs.Rather than explicitly constructing and serializing/deserializing objects, the application layer just requests objects from the current "context", according to their characteristics. The context manages database connections, object state changes, references, relationships, in-memory transactions, queries and caching in tunable ways.Accessors dynamically fabricate references lazily, as needed through the same query API, so objects work as the developer would traditionally expect in most cases. The goal of UR::Object is that your application doesn't have to do data management. Just ask for what you want, use it, and let it go.UR::Objects support full reflection and meta-programming. Its meta-object layer is fully self-bootstrapping (most classes of which UR is composed are themselves UR::Objects), so the class data can introspect itself, such that even classes can be created within transactions and discarded.SYNOPSISCreate a new object in the current context, and return it: $elmo = Acme::Puppet->create( name => 'Elmo', father => $ernie, mother => $bigbird, jobs => , favorite_color => 'red', );Plain accessors work in the typial fashion: $color = $elmo->favorite_color();Changes occur in a transaction in the current context: $elmo->favorite_color('blue');Non-scalar (has_many) properties have a variety of accessors: @jobs = $elmo->jobs(); $jobs = $elmo->job_arrayref(); $set = $elmo->job_set(); $iter = $elmo->job_iterator(); $job = $elmo->add_job($snore); $success = $elmo->remove_job($sing);Query the current context to find objects: $existing_obj = Acme::Puppet->get(name => 'Elmo'); # same reference as $existing_obj @existing_objs = Acme::Puppet->get( favorite_color => , ); # this will not get elmo because his favorite color is now blue @existing_objs = Acme::Puppet->get(job => $snore); # this will return $elmo along with other puppets that snore, # though we haven't saved the change yet..Save our changes: UR::Context->current->commit;Too many puppets...: $elmo->delete; $elmo->play; # this will throw an exception now $elmo = Acme::Puppet->get(name => 'Elmo'); # this returns nothing nowJust kidding: UR::Context->current->rollback; # not a database rollback, an in-memory undoAll is well: $elmo = Acme::Puppet->get(name => 'Elmo'); # back again! Requirements: · Perl

UR::Object Related Software