config()method of a model that relates to another model within your application.
postid, then we would have this
config()method within our comment model:
post / commentrelationship mentioned above for
belongsTo(). If we were to talk to ourselves, we would say, "A post has many comments." And that's how you should construct your post model:
comments. No need to worry: Wheels understands the need for the plural in conjunction with the
profile. A lot of websites allow you to enter required info such as name and email but also allow you to add optional information such as age, salary, and so on. These can of course be stored in the same table. But given the fact that so much information is optional, it would make sense to have the required info in a
userstable and the optional info in a
profilestable. This gives us a
hasOne()relationship between these two models: "A user has one profile."
profilemodel would look like this:
user hasOne() profile, and a
user. Generally speaking, all associations should be set up this way. This will give you the fullest API to work with in terms of the methods and arguments that Wheels makes available for you.
profileis dependent on a
user. When you delete the
user, you would usually want to delete the
dependentwith one of the following values, and CFWheels will automatically deal with the dependency.
hasMany()associations, but not
employeestable and share the same
employeestable will be joined to itself using the
manageridcolumn. CFWheels will handle the aliasing of the (otherwise duplicated) table names. It does this by using the pluralized version of the name you gave the association (in other words "managers" in this case).
idappended to the end. So to link up our table to the
employeestable, the foreign key column should be named
foreignKeyargument in your models'
post, but you didn't use the naming convention and instead called the column
author_id. (You just can't seem to let go of the underscores, can you?)
config()method would then need to look like this:
authorstable automatically so that you can use that data along with the data from
includeargument. You can for example return data for
authors, posts, and
biosin one call like this:
postmodel instead of on the
commentmodel. (Looking at the
commentmodel is the default behavior when not using parenthesis.)
selectargument in the finder functions.
namein both your
authorstables, then you could use the
selectargument like so:
comments. What happens then is that Wheels will enrich the post model by adding a bunch of useful methods related to this association.
commentsthat have been submitted for a
post, you can now call
post.comments(). In the background, Wheels will delegate this to a findAll() call with the
whereargument set to
XXXbelow with the name of the associated model (i.e.
commentsin the case of the example that we're using here).
NULL. Similar to calling
NULL. Similar to calling
post.comments(order="createdAt DESC"), and the
orderargument will be passed along to
author.setProfile(profile)will perform the same task as
author.setProfile(1). (Of course, we're assuming that the
profileobject in this example has a primary key value of
author.posts()call in the scenario above, for example.
XXX()method, perhaps we'd want to limit a
post's comment listing to just ones created today. We can pass a
whereargument similar to what is passed to the
findAll()function that powers
XXX()behind the scenes.
customercan be subscribed to many
publicationscan be subscribed to by many
customers. In our database, this relationship is linked together by a third table called
subscriptions(sometimes called a bridge entity by ERD snobs).
subscriptionbridge entity to get the same effect:
shortcutargument to hasMany(), you can have Wheels create a dynamic method that lets you bypass the join model and instead reference the model on the other end of the many-to-many relationship directly.