FarCry does things a little bit differently to other frameworks. Why concentrate on generating componentry and code by introspecting a database table, when you could be doing the complete opposite.
By constructing a ColdFusion component, and defining a series of cfproperty tags with rich metadata we define a blueprint for how an aspect of the application should behave. In the first instance this "blueprint" defines how FarCry should put together the underlying database schema.
The thinking behind FourQ (the ORM for FarCry) was simply that the developer should be able to code independently from the way the data is stored. To put some historical perspective on it, the original FourQ was written during the Neo Alpha in an effort to port Spectra databases to a new component based coding model. We were unhappy with the data model being used in Spectra, namely its reliance on encapsulating content objects in WDDX. But liked the concept that content should be treated as discrete objects.
FourQ gave us an opportunity to build code bases that were not tied to any specific data structure. It acts as a transformation layer that converts traditional relational tables and records into a "content object" that can be used in the FarCry framework.
Of course FourQ has evolved considerably since the early naughties when it was first conceived. But the underlying principles of going from code base to data model rather than the reverse still apply.