Support storing binary data

[GoogleCodeExporter]

The code in the $create function of crud.cfm apparently forces an implicit 
cast to varchar by trying to determine if the field is null.  This cast 
will fail if the data happens to be binary.  The result is that Wheels 
cannot save binary data to the database.  I'm not sure if similar issues 
occur in Update().

See the very last portion of this statement: 

loc.param = {value=this[loc.key], 
type=variables.wheels.class.properties[loc.key].type, 
scale=variables.wheels.class.properties[loc.key].scale, list=false, 
null=this[loc.key] IS ""}; 

Original issue reported on code.google.com by dscot...@gmail.com on 26 Jan 2009 at 5:25

[GoogleCodeExporter]

I think it can be resolved by simply replacing this code:
   null=this[loc.key] IS ""
with this code:
   null=len(this[loc.key]) eq 0

Need to change both $create() and $update() in crud.cfm.

Original comment by dscot...@gmail.com on 26 Jan 2009 at 7:45

[GoogleCodeExporter]

A related issue is present in the hasChanged() method.  The following portion 
of code 
results in an error when comparing binary fields:

    this[loc.key] IS NOT variables.$persistedProperties[loc.key] &&

Original comment by dscot...@gmail.com on 30 Jan 2009 at 1:09

[GoogleCodeExporter]

After continuing to work on a project that needed to use binary/image types, I 
uncovered more and more issues with Wheels handling of it.  I would workaround 
an 
issue in one function, only to have another similar issue spring up somewhere 
else.  
I've given up.  If you try to save and retrieve/update binary data, I'm sure 
you'll 
be able to find all the issues.

Original comment by dscot...@gmail.com on 2 Feb 2009 at 1:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

There is another problem in $update() on a different line of code than that 
which is 
referred to in Comment #1.  This second issue was in one of the conditions of 
the if 
statement:
(StructKeyExists(this, loc.key) && 
(!StructKeyExists(variables.$persistedProperties, 
loc.key) || this[loc.key] IS NOT variables.$persistedProperties[loc.key])

I think it may have been the last condition in that statement.  I attempted to 
fix it 
using the same approach as I did for the others, but this time it didn't work.  
I 
concluded using binary data in Wheels had never been attempted, and I didn't 
really 
want to get that deep into the framework code at this point.  Don't get me 
wrong.  I 
think Wheels code is the best CF-based code I've ever seen, but I just don't 
have a 
passion for CF that much (I'm a .NET programmer forced to use CF at work.  Can 
you 
feel my pain?)

Original comment by dscot...@gmail.com on 2 Feb 2009 at 6:15

[GoogleCodeExporter]

"I concluded using binary data in Wheels had never been attempted"

That is correct. I personally prefer to store binary data in the file system so 
I 
never considered adding support for it myself. I'll see what I can do though, 
perhaps 
it can get added at some point but don't count on it happening anytime soon.

Original comment by per.djurner@gmail.com on 2 Feb 2009 at 9:13

[GoogleCodeExporter]

Original comment by per.djurner@gmail.com on 23 Feb 2009 at 6:05

• Changed title: Support storing binary data
• Changed state: Accepted
• Added labels: Type-Enhancement, Milestone-1.1
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by per.djurner@gmail.com on 7 Mar 2009 at 9:26

• Added labels: Milestone-1.2

[GoogleCodeExporter]

Original comment by tpetru...@gmail.com on 12 Apr 2009 at 2:50

[GoogleCodeExporter]

Original comment by tpetru...@gmail.com on 29 Jun 2009 at 10:45

• Added labels: Milestone-1.1
• Removed labels: Milestone-1.2

[GoogleCodeExporter]

Issue 314 has been merged into this issue.

Original comment by per.djurner@gmail.com on 13 Nov 2009 at 11:41

[GoogleCodeExporter]

Original comment by per.djurner@gmail.com on 16 Nov 2009 at 1:50

• Added labels: Milestone-1.2

[GoogleCodeExporter]

Original comment by per.djurner@gmail.com on 6 Dec 2009 at 6:05

• Removed labels: Milestone-1.2

[GoogleCodeExporter]

Note: as a part of this issue we should look into supporting objects stored in 
Postgres. The work that needs to be done is probably very similar. See issue 
416 for more info.

Original comment by per.djurner@gmail.com on 16 Jun 2010 at 9:05

[GoogleCodeExporter]

Original comment by tpetru...@gmail.com on 7 Jul 2010 at 1:32

• Changed state: Started

[GoogleCodeExporter]

Original comment by tpetru...@gmail.com on 13 Jul 2010 at 4:43

• Changed state: UnderReview

[GoogleCodeExporter]

Original comment by tpetru...@gmail.com on 15 Jul 2010 at 6:07

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision r4685.

Original comment by tpetru...@gmail.com on 15 Jul 2010 at 7:03

• Changed state: Fixed