|
This message is just to let you know that I’ve
recently made a number of changes to OO queries (they were totally rewritten)
and to iterators as well as a few other small areas. (As always, delete your
project files.) The notes on these updates can be seen here: http://trac.reactorframework.com/reactor/trac.cgi/timeline
on 5/28 and 5/31. For the most part, OO queries have the same API they always
did. The biggest differences are with the join method(s), the
returnObjectField(s) methods and the new setFieldPrefix method. The join method now has a different signature. It now
looks like this: join(fromObjectAlias, toObjectAlias, relationshipAlias) In particular, the type of join has been removed from the
method (more on this in a second) and the prefix argument has been removed. The
from and to object aliases should be pretty clear. The relationship alias
indicates which relationship is being used to do the join. For example,
if you had a user with fields for address1 and address2 which are both foreign
keys to an address table you’re going to have two relationships from user
to address. Reactor needs to know which relationship to use when
joining. Here’s an example configuration: <object name=”user”> <hasOne
name=”address” alias=”address1”> <relate
from=”addressId1” to=”addressId” /> </hasOne> <hasOne
name=”address” alias=”address2”> <relate
from=”addressId2” to=”addressId” /> </hasOne> </object> <object name=”address” /> Here’s some code joining to the user to the address via
the address2 relationship <!--- assuming we already have a usergateway ---> <cfset query = userGateway.createQuery() /> <cfset query.join(“user”, “address”,
“address2”) /> <!--- dump the results ---> <cfdump var=”#userGateway.getByQuery(query)#”
/> FYI, the relationship does not need to exist on the from
object. If you want you can identify a relationship on the object you’re
joining to. Sean has expressed distaste about a few things regarding
this. I disagree with him in most cases, but one point he’s right on
and that I’m thinking about is if the relationshipAlias should be
required. I assume that in 90% of the cases you’re only going to
have one relationship between the from and to object. Based on that,
maybe reactor should guess. In cases where there is more than one
relationship but the relationshipAlias is not provided that would cause an
error. I’m leaning away from this because you could code something
that works, but come in and add a second relationship to another object months
later and by doing that introduce an unexpected error into your app in a
possibly unrelated location. Moving on… The returnField method has been renamed to returnObjectField
to be more consistent with the returnObjectFields method. Because the prefix argument was removed from the join method
I added a method called setFieldPrefix which will prepend a prefix to the alias
of all fields for an object in a query. The signature for this is: returnFieldPrefix(objectAlias,prefix) Lastly, I added four join methods, innerJoin() (called by
join()), leftJoin(), rightJoin() and fillJoin(). Each of these has the
same signature as the join method. I did the separate methods to simplify
the signature of the join method. Of particular note with the update is that I removed query pooling
(at least for now). This was one of my suspected areas for the memory
leak. I’m not certain, but I think it’s made a significant
impact. My blog has been running for about a day now and is only using
177 megs of ram, rather than 600 and some. However, it has still been
stepping up over time. For this reason I’m not convinced I’m
out of the woods yet. More tests and time will tell. I also removed some objects and lessened the number of object
instantiations required for OO queries. Even without pooling in my simple
tests the queries seem to run just as fast as with pooling. (Let me know
what your experience is with this.) So that’s it with oo queries. There were a few
bugs related to, for lack of a better term, cascading saves to iterators.
In some configurations they were throwing errors. This was due to the
relationships not being explicit (same as oo queries). My updates
addressed these issues in the iterator.cfc and the abstractRecord. I think that’s pretty much it. Soon we’ll have a bug tracker! Doug -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ |
- [Reactor For CF] Update to OO queries and Iterators Doug Hughes
