=pod

=head1 NAME

UR::Object - transactional, queryable, process-independent entities

=head1 SYNOPSIS

Create a new object in the current context, and return it:

  $elmo = Acme::Puppet->create(
    name => 'Elmo',
    father => $ernie,
    mother => $bigbird,
    jobs => [$dance, $sing],
    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 => ['red','yellow'],
  );
  # 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 now

Just kidding:

  UR::Context->current->rollback; # not a database rollback, an in-memory undo

All is well:

  $elmo = Acme::Puppet->get(name => 'Elmo'); # back again!

=head1 DESCRIPTION

UR::Objects are transactional, queryable, 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.

=head1 INHERITANCE

  UR::ModuleBase    Basic error, warning, and status messages for modules in UR.
    UR::Object      This class - general OO transactional OO features

=head1 WRITING CLASSES

See L<UR::Manual::Tutorial> for a narrative explanation of how to write clases.

For a complete reference see L<UR::Manual::WritingClasses>.

For the meta-object API see L<UR::Object::Type>.

A simple example, declaring the class used above:

  class Acme::Puppet {
      id_by => 'name',
      has_optional => [
          father => { is => 'Acme::Puppet' },
          mother => { is => 'Acme::Puppet' },
          jobs   => { is => 'Acme::Job', is_many => 1 },
      ]
  };

You can also declare the same API, but specifying additional internal details to make
database mapping occur the way you'd like:

  class Acme::Puppet {
      id_by => 'name',
      has_optional => [
          father => { is => 'Acme::Puppet', id_by => 'father_id' },
          mother => { is => 'Acme::Puppet', id_by => 'mother_id' },
      },
      has_many_optional => [
          job_assignments => { is => 'Acme::PuppetJob', im_its => 'puppet' },
          jobs            => { is => 'Acme::Job', via => 'job_assignments', to => 'job'  },
      ]
  };


=head1 CONSTRUCTING OBJECTS

New objects are returned by create() and get(), which delegate to the current
context for all object construction.

The create() method will always create something new or will return undef if
the identity is already known to be in use.

The get() method lets the context internally decide whether to return a cached 
reference for the specified logical entities or to construct new objects 
by loading data from the outside.

=head1 METHODS

The examples below use $obj where an actual object reference is required,
and SomeClass where the class name can be used.  In some cases the 
example in the synopsisis is continued for deeper illustration.

=head2 Base API

=over 4

=item get

  $obj = SomeClass->get($id);
  $obj = SomeClass->get(property1 => value1, ...);
  @obj = SomeClass->get(property1 => value1, ...);
  @obj = SomeClass->get('property1 operator1' => value1, ...);

Query the current context for objects.

It turns the passed-in parameters into a L<UR::BoolExpr> and returns all
objects of the given class which match.  The current context determines
whether the request can be fulfilled without external queries.  Data
is loaded from underlying database(s) lazliy as needed to fulfuill the 
request. 

In the simplest case of requesting an object by id which is cached, the
call to get() is an immediate hash lookup, and is very fast. 

See L<UR::Manual::Queries>, or look at L<UR::Object::Set>, L<UR::BoolExpr>, 
and L<UR::Context> for details.

If called in scalar context and more than one object matches the given 
parameters, get() will raise an exception through C<die>.

=item create 

  $obj = SomeClass->create(
    property1 => $value1,
    properties2 => \@values2,
  );

Create a new entity in the current context, and return a reference to it.

The only required property to create an object is the "id",
and that is only required for objects which do not autogenerate their
own ids.  This requirement may be overridden in subclasses to be 
more restrictive.
 
If entities of this type persist in an underlying context, the entity will
not appear there until commit.  (i.e. no insert is done until just before
a real database commit)  The object in question does not need to pass its own 
constraints when initially created, but must be fully valid before the
transaction which created it commits. 

=item delete

  $obj->delete

Deletes an object in the current context.  

The $obj reference will be garbage collected at the discretion of the Perl interpreter as soon as possible.  
Any attempt to use the reference after delete() is called will result in an exception.  

If the represented entity was loaded from the parent context (i.e. persistent database objects),
it will not be deleted from that context (the database) until commit is called.  The commit call
will do both the delete and the commit, presuming the complete save works across all involved
data sources.

Should the transaction roll-back, the deleted object will be re-created in the current context,
and a fresh reference will later be returnable by get().  See the documentation on L<UR::Context>
for details on how deleted objects are rememberd and removed later from the database, and how
deleted objects are re-constructed on STM rollback.

=item class

 $class_name = $obj->class;
 $class_name = SomeClass->class;

Returns the name of the class of the object in question.  See __meta__ below
for the class meta-object.

=item id 

 $id = $obj->id;

The unique identifier of the object within its class.  

For database-tracked entities this is the primary key value, or a composite
blob containing the primary key values for multi-column primary keys.

For regular objects private to the process, the default id embeds the
hostname, process ID, and a timestamp to uniquely identify the 
UR::Context::Process object which is its final home.

When inheritance is involved beneath UR::Object, the 'id' may identify the object 
within the super-class as well.  It is also possible for an object to have a 
different id upon sub-classification.


=back

=head2 Accessors

Every relationship declared in the class definition results in at least one
accesor being generated for the class in question. 

Identity properties are read-only, while non-identity properties are read-write
unless is_mutable is explicitly set to false.

Assigning an invalid value is allowed temporarily, but the current transaction
will be in an invalid state until corrected, and will not be commitable.

The return value of an the accessor when it mutates the object is
the value of the property after the mutation has occurred.


=head3 Single-value property accessors:

By default, properties are expected to return a single value.  

=over 4

=item NAME

Regular accessors have the same name as the property, as declared, and also work
as mutators as is commonly expected:

  $value = $obj->property_name;
  $obj->property_name($new_value);

When the property is declared with id_by instead of recording the refereince, it 
records the id of the object automatically, such that both will return different
values after either changes.

=back

=head3 Muli-value property accessors:

When a property is declared with the "is_many" flag, a variety of accessors are made 
available on the object.  See C<UR::Manual::WritingClasses> for more details
on the ways to declare relationships between objects when writing classes.

Using the example from the synopsis:

=over 4

=item NAMEs (the property name pluralized)

A "has_many" relationship is declared using the plural form of the relationship name.  
An accessor returning the list of property values is generated for the class.  It
is usable with or without additional filters:

  @jobs = $elmo->jobs();
  @fun_jobs = $elmo->jobs(is_fun => 1);

The singular name is used for the remainder of the accessors...

=item NAME (the property name in singular form)

Returns one item from the group, which must be specified in parameters.  If more
than one item is matched, an exception is thrown via die():

 $job = $elmo->job(name => 'Sing');
 
 $job = $elmo->job(is_fun => 1);
 # die: too many things are fun for Elmo
 
=item NAME_list

The default accessor is available as *_list.  Usable with or without additional filters:

  @jobs = $elmo->job_list();
  @fun_jobs = $elmo_>job_list(is_fun => 1);


=item NAME_set

Return a L<UR::Object::Set> value representing the values with *_set:

  $set  = $elmo->job_set();
  $set  = $elmo->job_set(is_hard => 1);


=item NAME_iterator

Create a new iterator for the set of property values with *_iterator:

  $iter = $elmo->job_iterator();
  $iter = $elmo->job_iterator(is_fun => 1, -order_by => ['name]);
  while($obj = $iter->next()) { ... }

=item add_NAME

Add an item to the set of values with add_*:

  $added  = $elmo->add_job($snore);

A variation of the above will construt the item and add it at once.
This second form of add_* automaticaly would identify that the line items
also reference the order, and establish the correct converse relationship
automatically.

  @lines = $order->lines;
  # 2 lines, for instance
  
  $line = $order->add_line(
     product => $p,
     quantity => $q,
  );
  print $line->num;
  # 3, if the line item has a multi-column primary key with auto_increment on the 2nd column called num

=item remove_NAME

Items can be removed from the assigned group in a way symetrical with how they are added:

  $removed = $elmo->remove_job($sing);

=back

=back

=head2 Extended API

These methods are available on any class defined by UR.  They
are convenience methods around L<UR::Context>, L<UR::Object::Set>,
L<UR::BoolExpr>, L<UR::Object::Viewer>, L<UR::Observer> 
and L<Mock::Object>.

=over 4

=item create_iterator

  $iter = SomeClass->create_iterator(
    property1 => $explicit_value,
    property2 => \@my_in_clause,
    'property3 like' => 'some_pattern_with_%_as_wildcard',
    'property4 between' => [$low,$high],   
  );
  
  while (my $obj = $iter->next) {
    ...
  }

Takes the same sort of parameters as get(), but returns a L<UR::Object::Iterator>
for the matching objects.

The  next() method will return one object from the resulting set each time it is 
called, and undef when the results have been exhausted.

C<UR::Object::Iterator> instances are normal object references in the current 
process, not context-oriented UR::Objects.  They vanish upon dereference,
and cannot be retrieved by querying the context.

=item define_set 

 $set = SomeClass->define_set(
    property1 => $explicit_value,
    property2 => \@my_in_clause,
    'property3 like' => 'some_pattern_with_%_as_wildcard',
    'property4 between' => [$low,$high], 
 );
 
 @subsets = $set->group_by('property3','property4');
 
 @some_members = $subsets[0]->members;

Takes the same sort of parameters as get(), but returns a set object.

Sets are lazy, and only query underlying databases as much as necessary.  At any point 
in time the members() method returns all matches to the specified parameters.

See L<UR::Object::Set> for details.

=item define_boolexpr 

 $bx = SomeClass->define_boolexpr(
    property1 => $explicit_value,
    property2 => \@my_in_clause,
    'property3 like' => 'some_pattern_with_%_as_wildcard',
    'property4 between' => [$low,$high],
 );

 $bx->evaluate($obj1); # true or false?
 
Takes the same sort of parameters as get(), but returns a L<UR::BoolExpr> object.

The boolean expression can be used to evaluate other objects to see if they match
the given condition.  The "id" of the object embeds the complete "where clause",
and as a semi-human-readable blob, such is reconstitutable from it.

See L<UR::BoolExpr> for details on how to use this to do advanced work on
defining sets, comparing objects, creating query templates, adding 
object constraints, etc.

=item add_observer 

 $o = $obj1->add_observer(
    aspect => 'someproperty'
    callback => sub { print "change!\n" },
 );
 
 $obj1->property1('new value');
 
 # observer callback fires....
 
 $o->delete;

Adds an observer to an object, monitoring one or more of its properties for changes.

The specified callback is fired upon property changes which match the observation request.

=item create_mock 

 $mock = SomeClass->create_mock(
    property1 => $value,
    method1 => $return_value,
 );
 
Creates a mock object using using the class meta-data for "SomeClass" via L<Mock::Object>.

Useful for test cases.

=back

=head2 Meta API 

The folowing methods allow the application to interrogate UR for information
about the object in question.

=over 4

=item __meta__
  
  $class_obj = $obj->__meta__();

Returns the class metadata object for the given object's class.  Class objects
are from the class L<UR::Object::Type>, and hold information about the class' 
properties, data source, relationships to other classes, etc.

=item __errors__

  @tags = $obj->__errors__()

Return a list of L<UR::Object::Tag> values describing the issues which would 
prevent a commit in the current transaction.

The base implementation check the validity of an object by applying any constraints 
layed out in the class such as making sure any non-optional properties contain values, 
numeric properties contain numeric data, and properties with enumerated values only
contain valid values.

Sub-classes can override this method to add additional validity checking.

=item __display_name__ 

 $text = $obj->__display_name__;
 # the class and id of $obj, by default

 $text = $line_item->__display_name__($order);
 
Stringifies an object.  Some classes may choose to actually overload the stringification operator
with this method.  Even if they do not, this method will still attempt to identify this object in
text form.  The default returns the class name and id value of the object within a string.

It can be overridden to do a more nuanced job.  The class might also choose to overload the
stringification operator itself with this method, but even if it doesn not the system will 
presume this method can be called directly on an object for reasonable stringificaiton.

=item __context__ 

 $c = $self->__context__;

Return the L<UR::Context> for the object reference in question.

In UR, a "context" handles connextions between objects, instead of relying 
on having objects directly reference each other.  This allows an object
to have a relationship with a large number of other logical entities,
without having a "physical" reference present within the process in question.

All attempts to resolve non-primitive attribute access go through the context.

=back

=head2 Extension API

These methods are primarily of interest for debugging, for test cases, and internal UR development.

They are likely to change before the 1.0 release.

=over 4

=item __signal_change__ 

Called by all mutators to tell the current context about a state change.

=item __changes__ 

  @tags = $obj->__changes__()

Return a list of changes present on the object _directly_.  This is really only 
useful internally because the boundary of the object is internal/subjective. 

Changes to objects' properties are tracked by the system.  If an object has been 
changed since it was defined or loaded from its external data source, then changed() 
will return a list of L<UR::Object::Tag> objects describing which properties have been 
changed.

Work is in-progress on an API to request the portion of the changes in effect in the 
current transaction which would impact the return value of a given list of properties.  
This would be directly usable by a viewer/observer.

=item __define__ 

This is used internally to "virtually load" things.  Simply assert they already existed 
externally, and act as though they were just loaded...  It is used for classes defined in 
the source code (which is the default) by the "class {}" magic instead of in some database, 
as we'd do for regular objects.

=item __strengthen__

  $obj->__strengthen__();

Mark this object as unloadable by the object cache pruner.

UR objects are normally tracked by the current Context for the life of the
application, but the programmer can specify a limit to cache size, in 
which case old, unchanged objects are periodically pruned from the cache.
If strengthen() is called on an object, it will effectively be locked in
the cache, and will not be considered for pruning.

See L<UR::Context> for more information about the pruning mechanism.

=item __weaken__

  $obj->__weaken__();

Give a hint to the object cache pruner that this instance is not going to be used 
in the application in the future, and should be removed with preference when
pruning the cache.

=item DESTROY 

Perl calls this method on any object before garbage collecting it.  It 
should never by called by your application explicitly.

The DESTROY handler is overridden in UR::Object.  If you override it in
a subclass, be sure to call $self->SUPER::DESTROY() before exiting your
override, or errors will occur.

=back

=head1 ERRORS, WARNINGS and STATUS MESSAGES

When an error occurs which is "exceptional" the API will throw an exception via die().

In some cases, when the possibility of failure is "not-exceptional", the method will simply
return false.  In scalar context this will be undef.  In list context an empty list.  

When there is ambiguity as to whether this is an error or not (get() for instance, might 
simply match zero items, ...or fail to understand your parameters), an exception is used.

=over 4

=item error_message

The standard way to convey the error which has occurred is to set ->error_message() on 
the object.  This will propagate to the class, and through its inheritance.  This is 
much like DBI's errstr method, which affects the handle on which it was called, its source
handle, and the DBI package itself.

=item warning_message

Calls to warning_message also record themselves on the object in question, and its class(es).

They also emit a standard Perl warn(), which will invoke $SIG{__WARN__};

=item status_message

Calls to status_message are also recorded on the object in question.  They can be 
monitored through hooks, as can the other messages.  

=back

See L<UR::ModuleBase> for more information.

=back

=head1 SEE ALSO

L<UR>, L<UR::Object::Type>, L<UR::Context>

L<UR::Maual::Tutorial>, L<UR::Manual::WritingClasses>, L<UR::Manual::Queries>, L<UR::Manual::Transactions>

L<UR::ObjectDeprecated> contains additional methods which are deprecated in the API.

=cut

