As for CFC and Java class files, I am not sure that when the CFCs are
instantiated that you can distinctly see where the object class file is
related to that specific CFC. In truth, I have never looked for them. I
would be curious myself actually now that you mention it. ColdFusion is
meant to abstract many things.
-------------------
Hi Teddy,
I wouldn't be as interested in finding the resulting class FILE (I don't
think)... I think I'd actually be looking at how to take an instantiated
(CFC) object, which exists in memory (?), and treat it like a true Java
object... for example, could I take that object and pass it to an
instantiated (true) Java class (made available via CFOBJECT?), and have it
"go" (probably not) and be used by that object?
If you can instantiate a CFC, and then hand off that object to a regular
POJO, that opens up a whole new realm of possibilities. (I am still on MX
6.1 btw, in case that matters in this discussion).
Interesting discussion, though I know we're way OT as this point.
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Teddy Payne
Sent: Monday, July 31, 2006 4:30 PM
To: [email protected]
Subject: Re: [Reactor for CF] Views/SPs and Reactor, Definition of
Reactor
As for Fusebox 5, Model-Glue uses Reactor natively as its ORm
Service and Model-Glue has benchmarks that are rather impressive.
Teddy
On 7/31/06, Marc Funaro <[EMAIL PROTECTED]> wrote:
> 1. I am VERY used to putting many functions on the
> database tier. For example, using views to pare
down
> what people can see/do, or for complex joins that
are
> best handled by MSSQL and passed out as a simple
recordset.
> This has had the net effect of making my apps more
> efficient. Can someone outline how and where Views
and
> SPs fit in with the use of Reactor? Am I going to
have
> to give up some of the functions that make the db
tier
> more efficient?
>
> You can create custom methods on any gateway or record
> object to optimize a call. The downside is you
> reintroduce database specific dependancies.
Reactor supports database-specific dependencies quite
gracefully, from what
I understand so far. The goal is not to eliminate the
dependencies, but put
them where they belong. We're not looking to make our app
cross-database
(though reactor will let us do that using the db-specific
child classes)...
We just want to continue using the best parts of the
database tier wherever
possible, for the best scalability.
> 2. Looking for a general definition of reactor - is
it
> simply an ORM framework, and nothing more? Does it
> carry essentially the same purpose/mission statement
> as, say, Hibernate? Does it suffer similar
performance issues?
>
> It is more than a simple tool for automating the
> creation of CRUD and other persistence objects.
> Consequently it carries similar performance overhead.
> The largest impact to performance for me has been the
> object creation. If you minimize that the benefits can
> out weigh the negatives.
Is that the definition of Hibernate - simply a "tool for
automating the
creation of CRUD and other persistence objects"? In what
way is Object
CREATION the larger bottleneck? I would have thought the
re-instantiation
of complex objects, especially when returning larger
recordsets of them,
would have been the bottleneck point. Simply creating a new
object, or a
single object retrieved from the DB, is actually more of a
performance hit?
Has anyone done any real metrics on reactor, i.e. true
millisecond
reporting? I have been really pumped about how much better
Fusebox 5 is,
with regards to performance in production mode... I'd hate
to think that
reactor is going to turn around and take those performance
gains away again.
Thoughts anyone? Has this been discussed before?
>
>
> Thanks!
>
> Marc
>
>
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
> -- -- -- -- -- --
> -- -- --
> Reactor for ColdFusion Mailing List
> [email protected]
> Archives at:
>
http://www.mail-archive.com/reactor%40doughughes.net/
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
> -- -- -- -- -- --
> -- -- --
>
********************************************************
********************
> This email may contain confidential material.
> If you were not an intended recipient,
> Please notify the sender and delete all copies.
> We may monitor email to and from our network.
>
********************************************************
********************
>
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
> -- -- -- -- -- -- -- -- -- Reactor for ColdFusion
> Mailing List [email protected] Archives at:
>
http://www.mail-archive.com/reactor%40doughughes.net/
<http://www.mail-archive.com/reactor%40doughughes.net/>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
> -- -- -- -- -- -- -- -- --
>
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at:
http://www.mail-archive.com/reactor%40doughughes.net/
<http://www.mail-archive.com/reactor%40doughughes.net/>
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- --
--
<cf_payne />
http://cfpayne.wordpress.com/ <http://cfpayne.wordpress.com/>
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
