net.java.ao

Annotation Type OneToMany

@Retention(value=RUNTIME)
 @Target(value=METHOD)
public @interface OneToMany

Marks a method as relevant only to a one-to-many relation. This informs ActiveObjects that the return value for the method in question should be determined from a one-to-many relation onto the type in the return value. For example:

public interface Company {
     // ...

     @OneToMany
     public Person[] getEmployees();
 }

Thus the return value of the getEmployees() method would be determined by a query something like the following:

SELECT id FROM people WHERE companyID = ?

If the where() clause is specified, it will be used in addition to the base, necessary criterion to determine the returned entities. Thus, the one-to-many relation could be referenced in the following way:

public interface Company {
     // ...

     @OneToMany(where="deleted = FALSE")
     public Person[] getEmployees();
 }

This would lead to a query like the following:

SELECT id FROM people WHERE companyID = ? AND (deleted = FALSE)

Author:

Daniel Spiewak

Optional Element Summary

Optional Elements

Modifier and Type	Optional Element and Description
java.lang.String	reverse The name of the corresponding getter method in the entities returned by the annotated method.
java.lang.String	where A String clause allowing developer-specified additional conditions to be imposed on the relationship.

Element Detail

reverse

public abstract java.lang.String reverse

The name of the corresponding getter method in the entities returned by the annotated method.

If this is not specified, a warning will be logged at migration time, and ActiveObjects may behave in unexpected ways. Future versions of ActiveObjects may require that this property be specified.

See Also:

AO-325

Default:

""

where

public abstract java.lang.String where

A String clause allowing developer-specified additional conditions to be imposed on the relationship. The String must be a proper SQL WHERE clause:

"deleted = FALSE"

One must be extremely careful with this sort of thing though because sometimes (as is the case with the above sample), the unparameterized code may not execute as expected against every database (due to differences in typing and value handling). Thus, in all but non-trivial cases, defined implementations should be used.

Default:

""