Ha, well that would be ridiculous if I was using some type of large binary object as a primary key, an mp3 of a user's favorite song or something. In fact the table is part of a data warehouse, and the primary key is an MD5 hash (16 bytes). It's just simpler to save the value as a binary value (in Oracle 10g as a 16 byte RAW datatype) instead of a string representation of the hex value or something like that.
Ryan On Dec 9, 3:51 pm, Mark Mandel <[email protected]> wrote: > So odd question - 'cause I've never heard of someone use a BLOB/CLOB/text as > a primary key, is that even allowed in the database you are using? > > I would have thought that would be too large a column data set to index. > > Mark > > > > > > On Thu, Dec 10, 2009 at 7:30 AM, Ryan Lynch <[email protected]> wrote: > > So, some digging by a colleague pinpointed the problem. In the > > writePrimaryKeyDefault() function in > > transfer.com.dynamic.definition.InitWriter, the switch statement > > starting on line 229 is missing a case for binary datatypes, and falls > > on the default case which writes the incorrect line. There should be > > an additional case for binary datatypes added to it. I've generated a > > patch using diff, and I can e-mail it to whoever it concerns. > > > On Dec 9, 3:00 pm, Ryan Lynch <[email protected]> wrote: > > > It looks like I deleted it off of the message but this relates to > > > Transfer v1.1 Final, and I'm using ColdFusion MX7. > > > > On Dec 9, 2:51 pm, Ryan Lynch <[email protected]> wrote: > > > > > I was going to file this in the issue tracker for Transfer, but it > > > > doesn't appear that I can so here goes: > > > > > Summary: > > > > > Creating an object definition with an id (in this case with a name of > > > > "id") of type binary results in the following error when a new > > > > transfer object is created using the transfer.new() function: > > > > > "The argument ID passed to function setid() is not of type binary." > > > > > Here is the id definition for the object from the transfer.xml file: > > > > > <id name="id" column="Id" type="binary" /> > > > > > Possible cause and solution: > > > > > Looking at the stack trace, the following line in the init() function > > > > defined in the generated object defintion passes the incorrect > > > > argument to the setid() function: > > > > > setid(getNullable().getNullString(getClassName(), "id")); > > > > > The correct code should be: > > > > > setid(getNullable().getNullBinary(getClassName(), "id")); > > > > > Changing this line manually fixes the problem. This is the only fix I > > > > have at the moment as I can't override the init() function using a > > > > decorator as that function is also defined in > > > > transfer.com.TransferDecorator, and I'm not familiar enough with the > > > > transfer source to find where the object definitions are generated and > > > > fix the problem there. If someone could point me to where that occurs > > > > in the source I'll gladly take the time to generate a patch. > > > -- > > Before posting questions to the group please read: > > >http://groups.google.com/group/transfer-dev/web/how-to-ask-support-qu... > > > You received this message because you are subscribed to the Google Groups > > "transfer-dev" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > >http://groups.google.com/group/transfer-dev?hl=en > > -- > E: [email protected] > T:http://www.twitter.com/neurotic > W:www.compoundtheory.com -- Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en
