>> 2. Keeping it in XML format
> Not so good. My objection here is that appending to the
> log would be prohibitively expensive. If you're doing
> logging, the format of your file needs to be something
> you can append to without needing to do any messing with
> the rest of the file. Because XML requires a root
> element, this makes using it for log files a bit
> impractical.
Yes and no... I suspect you're thinking about traditional "log"
applications where the log is stored in a flat file, like the
ColdFusion server logs, which would explains the thinking about it
being prohibitively expensive... If you had to deserialize the whole
file and then serialize the whole file again each time you wrote to
the log this would be true. There are a couple ways to get around some
of this overhead with a flat file. One is to store the deserialized
packet in persistent memory (application scope in all likelyhood) and
then simply append the child node and write the log using toString().
This would eliminate half of the overhead.
The other option is to view each line of the log as its own xml packet
(minus the <?xml ...?> declaration, which is still valid xml) this way
any individual line of the log could be viwed, serialized or
deserialized individually. You wouldn't have to use any of CF's XML
functions to insert new records into the log either, just wrap
<cfsavecontent> around some text to output your xml (using
#xmlformat()# for dynamic data of course) and write to the log file
normally using <cffile action="append"> ... This would eliminate _all_
the overhead involved in serializing and deserializing the packet for
each write to the log. If you needed to read the entire log at one
time (instead of just an individual log entry) then you could simply
use XMLParse("<log>#file#</log>") to get a single xml packet. (I think
Keith described this in his last message, but the description was a
little cryptic to me -- took me a minute to figure out what I think he
was saying).
However, if we're talking about a transaction log which would be used
for undo operations -- a complete application audit-trail -- then a
single flat-file log is likely _not_ the best way to handle this.
Sure, it could work for a small site/application, but for scalability
and for storing historical events potentially dating back several
years (we're not talking about a CF application log that would be
wholesale-deleted frequently), you would want to store the data in a
database table.
I'm actually in the process of working out the last details of just
such an event log system for the onTap framework's Members onTap
member-management and security plugin, with undo functionality being a
built-in consideration. My recommendations (asside from using the
framework :) are to store the current user ID in a separate column in
your database for the efficiency of SQL searching, to store the
userid, user's name (John Smith, not their "username" they use to log
in) and email address in the xml, because if you delete the user
later, you'll want to retain a record of who performed the task and
potentially how to contact them. Other than that, I store all the
attributes for the event (url and form variables) as attributes in the
XML packet, which should make the undo/rollback functionality easier,
since you can pass the xml.xmlAttributes object into the
argumentcollection or attributecollection of either the cfinvoke or
cfcomponent tags respectively.
hth
s. isaac dealey 954.522.6080
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.fusiontap.com
http://coldfusion.sys-con.com/author/4806Dealey.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:209542
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
