|
That’s an error. I didn’t mean to leave
it in there. I was doing some timing tests. Oooooops. I’ll fix in a bit. Doug From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy Payne Ruh Roh Shaggy! On 5/31/06, Doug
Hughes <[EMAIL PROTECTED]>
wrote: 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
- Re: [Reactor For CF] Update to OO queries and Iterators Teddy Payne
- RE: [Reactor For CF] Update to OO queries and Iterato... Doug Hughes
