Java Doc for SFieldReference.java in  » Database-ORM » SimpleORM » simpleorm » core » Java Source Code / Java DocumentationJava Source Code and Java Documentation

For example, assume that Employee has a DEPT_ID field that refers to Department.DEPT_ID. The Employee record would normally be declared as follows:-

It is also possible to declare the foreign key fields explicitly, which enables extra parameters such as column names to be explicitly specified. For example:-

Explicitly storing the foreign key fields means that there is no need to have a Department record instance in order to retrieve an Employee. Only if one calls Employee.getDepartment is the Department record created. It also alows overlapping foreign keys to be supported later (where two References may share a column).

Fields are normally created in static initializers of class constants (although this is not necessary). The java initialization rules generally work well to ensure that referenced records are initialized before referencing records. However, it may occasionally be necessary to create references in a second pass, particularly if there are mutually recursive references.

To understand the underlying data structures you really need to look at the E-R diagram.

E-Mail Extracts:- First of all let me note that the problem that you are dealing with is the mapping what used to be called a conceptual model and the relational/logical model. In the traditional "three schema model" generators work from conceptual through logical to physical models.

Since the advent of OO technology, the words have changed but the problems remain the same. Generating the relational schema from the conceptual one used by SimpleORM is quite fiddly, and is the most complex code in SimpleORM. Going the other way is, in general, much harder -- you are squeezing the toothpaste back into a tube, and not necessarily the same type of tube from whence it came.

However, in your quick start you do not have to solve all problems. Just generate the easy, common cases. Remember that the user can add foreign key definition in their subclass -- there is no reflection. So please focus on the simple, consistent cases.

As Richard implies, it is a fundamental assumtion of SimpleORM that records only contain one Primary key, and that that all foreign keys use it. No candidate keys considered. This is pretty fundamental to the way SimpleORM works -- the cache is keyed by the primary key, only.

So that is why you only need to specify the referencing record, but may in general have to specify all the referencing fields. This is why fields are *not* specified as SFieldReference(SRecordMeta meta, SFieldMeta[] localKeys, SFieldMeta[] foreignKeys)

which is a relational approach. SimpleORM assumes that foreign keys are generally defined in a consistent manner. This produces succinct code. I have not tried to make the processing of inconsistent names elegant because I assume (wrongly?) that it is rare.

This raw initializer is only useful to add extra specifications to the explicit definitions of the foreign key fields. This is rare in practice.

Each created foreign key column has the same name and type as the one in the referenced table but the names can be prefixed by prefix which is handy if for example, an Employee had a Managing_Department and a Billing_Department.

The main use of this function is to access the foreing key values of references without having to actually query the database.

(Note that this purpose will become obsolete once the lazy findOrCreate is implemented because just referencing the key value of the referenced object will not trigger the query.)

Normally, if the field is null but all the primary key fields are non null then does a findOrCreate() to provide a referenced record. SQY_REFERENCE_NO_QUERY suppresses this query. getReferencedWhileDetached may be called for detached records.