So here's an alternative to the "plain old CFC" (POC) approach (this
"annotation" model is something we actually considered and may still be open
to implementing). Persisting a CFC could mean:
"Only persist those variables that you (the CFML developer) specifically
declare to be persistable, via CFPROPERTY or some other annotation
mechanism. Searching can be done on any persistable variable that is a
simple type (string, number, boolean, date). When you read a CFC from the
datastore, create a new CFC instance and populate it with the persisted
variables."
This is certainly doable. One advantage it has over the POC approach is that
it avoids the versioning problem; another is that it's more like Java object
persistence, so if you're familiar with that then you're working with the
same conceptual framework (though I'd really be cautious about blindly
marching down the "make it work like Java" path, since CFML is not Java).
The disadvantages compared to the POC approach are that it's more complex
(you now have to understand how to do persistence annotations), and when you
read a CFC from the datastore you're not really getting back the same CFC
that you wrote out. With the "annotation" approach you're really not
persisting a CFC at all--you're persisting some data that you later use to
initialize a new CFC instance.
So there are two different approaches to CFC persistence. My preference is
for the POC approach, and to hide as many implementation details as possible
from the CFML developer (I think this is in the overall spirit of CFML).
Vince
On Fri, Jun 5, 2009 at 2:20 PM, Vince Bonfanti <[email protected]> wrote:
> I think you're getting too hung up on "serialization" as an implementation
> detail of the CFC persistence layer. The real questions are: What does it
> mean to save/restore a CFC to/from a persistent datastore? and, How does the
> CFML developer deal with the CFC persistence layer?
>
> For Java objects, persistence means to just save the data members, not the
> "behavior" members (methods). This might make sense for a static language;
> and, consider the complex annotation "language" (JDO) that's been developed
> to manage persistence. Go take a look at the GAE group and you'll see most
> of the questions revolve around use JDO.
>
> CFML isn't Java, CFCs aren't Java objects, and CFML developers aren't Java
> programmers. CFML is a dynamic language: you can add/remove behaviors
> (functions) from CFCs at will, you can change the types of variables, you
> can have one CFC instance that has some variables defined and another CFC
> instance of the same type that doesn't. None of this is true for Java, which
> is a static language. So the model for dealing with CFC persistence can't be
> the same as the model for dealing with Java object persistence.
>
> Forget about serialization as an implementation detail, and step back to a
> higher level: as a CFML programmer, how do you want CFC persistence to work?
> Here are my (initial) answers to this question:
>
> 1) I want it to be simple. I want to write a "plain old" CFC (without any
> persistence annotations) to the datastore and then read it back out again,
> and get back the exact same CFC that I wrote out.
>
> 2) I want to be able to query the datastore based on any variable I place
> in the CFC "this" or "variables" scope, again, without having to do any
> persistence annotations.
>
> 3) I want it to be fast so that I don't have to worry (too much) about
> performance.
>
> The current implementation reflects the above.
>
> So now we have the issue of CFC versioning (an important issue). Again,
> without referring to any implementation details, as a CFML programmer, how
> do you want this to work? If we can answer that question, then we can worry
> about the implementation details.
>
> Vince
>
>
--~--~---------~--~----~------------~-------~--~----~
Open BlueDragon Public Mailing List
http://groups.google.com/group/openbd?hl=en
official site @ http://www.openbluedragon.org/
!! save a network - trim replies before posting !!
-~----------~----~----~----~------~----~------~--~---
