This is the last thing on my list of things to do before doing leaving
the code base stable for the 0.6.1 release, but I wanted to run it
past the group.

Essentially, I was thinking about error handling - and figured that I
would wrap each of the public methods that Transfer has, like save()
and new() and delete() etc in try, catch block, and if an error
occurred during the processing, I would discard() the current object,
and rethrow the error.

I figured I would do this, as it would remove some of the chance
(there is always a chance) that there is dirty data in the cache if
something happens to go wrong, thus causing further issues.

I wanted to run this past the list, as I didn't want to end up
building something that assumed it was smarter than the developer
using it.

Can anyone think of any scenarios in which this would be a bad thing?
Obviously there would be a control to ensure that a discard operation
that threw an error didn't send the system into an infinite loop.

Just wanted to get your thoughts before I did any more work.

Otherwise, assuming no one finds anything in the current code base for
the next week or so, I'll be looking at doing the 0.6.1 release
towards the end of next week, or early the week after.

Look forward to hearing your thoughts.

Mark

Because of that, in many ways I'd rather you did *not* discard() dirty
data silently on an exception because if there really *is* dirty data
- and I've not seen the scenario in real-world usage yet - then it
would help debug it quicker if you trip over the dirty data locally
(as opposed to only having an out-of-sync clustered cache...
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

Hopefully this makes sense, as I'm thinking it out as I type.

For a clustered environment, I would guess that if something went
wrong currently, (I dunno, someone changes a database field in the DB
without a Transfer definition being updated.. or something), then the
local version would be out of sync, and the rest of any clustered
versions would be fine.

With my new proposal, if something went wrong, the local version would
still be okay, as it's been discarded, and the clustered versions
would be fine, as if something goes wrong, the data is not saved.

Now that I really think about it, I can't see a case when something
went wrong, and the clustered data could end up being dirty, simply
because if something goes wrong, no data should be commited to the
database.

This isn't to push my idea, just trying to work out a case in which
you could actually cause dirty data on the cluster.

Mark

On 1/2/07, Sean Corfield <seancorfi...@gmail.com> wrote:

There is a CFC that is hooked into the onAfterDelete event (for
example), with a code error in it, like a divide by zero error.

The object goes to delete, the delete is committed to the database,
and the afterDeleteEvent fires, causing an error - which then discards
the object, but I'm figuring will also not allow you to update your
clustered environment?

A couple of thoughts on that:

1) You would hope that would get picked up in testing, but sometimes
things do not
2) I could wrap the try/catch blocks to not do work on 'after' events,
thus ensuring that they won't discard() valid data (which is actually
a good idea).... in fact, the more i think about it, I may just avoid
the try/catch around event actions at all.

So that leaves me still leaning towards the enhancement, but a more
finely tuned one.

Mark

On 1/2/07, Sean Corfield <seancorfi...@gmail.com> wrote:

Yeah, I think it's fair to say that this change doesn't make my world
any worse...
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

I think I'm going to leave this one out for now, since I think I'll
end up ripping out all the code in the long run.

For a future release, I'm thinking of building something that looks like;

<cfset transaction = getTransfer().getTransaction()>

<cftry>
  <cfset transaction.begin()>
  <cfset getTranser().save(a)>
  <cfset getTranser().save(b)>
  <cfset getTranser().save(c)>
  <cfset transaction.commit()>
   <cfcatch type="any">
      <cfset transaction.rollback()>
   </cfcatch>
</cftry>

This would not only manage your database transaction, but also if the
save on 'b' failing, then both 'a' and 'b' would be discarded to also
rollback the cache state.

This wouldn't be required, but would just take place over doing calls
like <getTransfer().save(a, false)> to tell Transfer to not use
internal Transactions.

Regards,

Mark

On 1/2/07, Sean Corfield <seancorfi...@gmail.com> wrote:

Hope that helps?

On 1/3/07, Nando <d.na...@gmail.com> wrote:

Since any value coming in from an HTML form is a string .. no such
thing as type there, i've been using beans that accept strings for all
values. This allows me to let anything in and validate it once it's in
the bean.

So i tried setting the nullable value for date to "",

  <nullValues>
    <date value="" />
    <boolean value="0" />
  </nullValues>

And found out that ColdSpring doesn't like that. So it seems there's a
minor incompatibility there. Here's the error i get:

 Bean creation exception during init() of transfer.TransferFactory
"" is an invalid date or time string.

The error occurred in
C:\CFusionMX7\wwwroot\coldspring\beans\DefaultXmlBeanFactory.cfc: line
539
Called from
C:\CFusionMX7\wwwroot\coldspring\beans\DefaultXmlBeanFactory.cfc: line
332
Called from
C:\CFusionMX7\wwwroot\Unity\trunk\ModelGlue\unity\loader\XmlConfigurationLo ader.cfc:
line 293

Ok, no problem, let's try something else:

<property name="dateLastFeatured" type="date" nullable="true"
nullvalue="" />

When i use this, ColdSpring doesn't complain, but a new transfer object
defaults to a datetime of now() instead of "", and i get an error if i
try to set the date to "".  OK, that's not going to work if i can't set
the null value i've chosen.

So it seems i need to use a magic value of some sort that is a date to
represent null, rather than an empty string. So let's forget about
trying to set a different nullable value and use the default value of
1/1/100.

<property name="dateLastFeatured" type="date" nullable="true" />

Ok, so now when i create a new transferObject, the default date value
is Now(), which is OK, but a little useless from a certain perspective
because i can't easily test if the intention of the user is "null" or
not when they fill out the form.

I think everyone is familiar with this difficulty. In a web form, an
null date is an empty string. There's no other way to represent it to
the user that would make sense to them. Numerics are in a similar
situation, but many times a 0 will do when the intention is "nothing".

This is the main reason i've come to the conclusion that beans that
accept values from web forms shouldn't use typed arguments,
particularly typed date arguments. In the world of HTML, dates are
strings, and if i want to validate a date in this world, i'm looking
for either an empty string or a date. If my bean doesn't accept an
empty string, then it can't accept a valid value for a date from a
form, none.

And then of course on insert or update to the db, I'll use cfqueryparam
to set the value to null if it's an empty string.

So then i started thinking that it would be very nice if transfer had a
method where i could create a dumb bean that would accept any value
from a form. Then, i could pass that bean to my validation object, and
then if it validated, pass that on to the TransferObject to persist it.
I'm still thinking that would be a good enhancement, because then my
dumb beans would automatically be updated with any change to the
transfer.xml. But maybe it's beyond Transfer's scope.

But even with a dumb bean, i'm still left with the problem that to a
user, a null date is an empty string. I can of course work around this
issue, setting my magic null value on any dates immediately after any
transfer.new() call, looking for that magic value in the form and
resetting it to "", creating my own dumb bean to accept the values from
the form, looking for "" and resetting it to the magic value, and
proceeding from there.

But perhaps life would be easier if Transfer would accept an empty
string as a null value for a date?

Or maybe i'm not seeing a better solution to reconcile the typeless
world of the web with the typed world of databases?