[Dbix-class] BUG? Unable to resolve relationship

[Ovid]

----- Original Message ----

> From: Ovid <publiustemp-dbic at yahoo.com>

> 1.  I've just created the object.  Having to call "discard changes" on something 
> with no changes seems very counter-intuitive to me.  If I view the creation as 
> the change, then "discard changes" implies that the creation will be discarded, 
> but that's obviously not the case.  I'm still not sure I understand what's 
> happening here.
> 2.  We have a very large performance-sensitive system.  Having to make a second 
> trip to the database isn't ideal for us.
> 3.  Since the "account_id" has "is_nullable" set to a true value, would it be 
> appropriate for DBIx::Class to assume that a missing nullable value is actually 
> NULL and thus not throw an exception here?

Just to clarify a point: this has caused some of our tests to fail, but not our production code.  The reason our production code has not failed is because we have some *bad* code we have not yet cleaned up.  We have something like this (this isn't quite true, but it would take too long to explain otherwise):

  my $object = $schema->resultset('Foobar')->create({
    attr1 => $extracted->{attr1}

    attr2 => $extracted->{attr2}
 
  attr3 => $extracted->{attr3}
    attr4 => $extracted->{attr4}
  });

Note the hard-coding of resultset and attribute names.  We've wanted to clean this up and reduce this to something conceptually closer to this:

  my $object = $schema->resultset($extractor->moniker)->create({
    map { $_ => $extractor->get($attr) } $extractor->extracted
  });

The latter isn't perfect but it avoids hard-coding and is more flexible, but if we can't extract a piece of data from our incoming XML, the "extracted" method won't return it (to us, the existence of something with a no value and the lack of existence are different).  Thus, the second, cleaner code won't work without forcing the database round-trip via $object->discard_changes for every create.  Assuming this behavior does not change, is there a cleaner way for us to do this without that database round trip?

Cheers,
Ovid
--
Buy the book         - http://www.oreilly.com/catalog/perlhks/
Tech blog            - http://use.perl.org/~Ovid/journal/
Twitter              - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6