Hi folks,
After bashing our heads against this one for.. oh.. 12 hours or so (2
6hour stretches.. mst your code is too twisted!) theorbtwo and I have, er,
changed somethings such taht it appears to now work with my convoluted
setup..
Let me attempt to explain what and why:
First, the schema consists of a set of tables like this:
Type (id, autoinc)
might_have Structure(type_id, belongs_to type)
has_many StructureFields (struct_id belongs_to structure,
field_id belongs_to Field)
The current 0.08 trunk code checks if sources PK's depend upon each other,
but only one level deep. So for the rel from StructureFields to Structure,
it was returning "pk not dependant upon structure" because structure
doesnt have an auto-inc PK.
We're re-written the entire pk_depends_on method, in ResultSource,
including some recursion. (So now that part discovers that while structure
cant provide the pk, it depends on type, which does).
I also changed __their_pk_needs_us in Row.pm to not only acknowledge that
a source depends on another source, but if so set that object to the rel
key in the calling object. (So when, for eg StructureField is found to
depend on Structure, the temp Structure object we already created (when
looking at it via Type) is assigned to the data we create StructureField
with.
(Reading over that paragraph, it makes no sense to me eitehr, but it seems
to help ;)
In general it helps prevent creating two temp copies of what are going to
be the same row, and prevents us from inserting twice if (see below)
in_storage is set.
The third change:
When recursing down inserts, after the "do this before inserting this
object", just after the actual insert of the current object, in_storage(1)
is now set, instead of at the bottom as before. This prevents us from
trying to insert the same object twice while recursing down its "after
insert" deps.
Make any sense to anyone? I'm committing to branch with most of the
debugging "prints" still in (but commented out)
Of course when trying to run the actual multi_create.t, mine now seg
faults.. sqlite probably?
Jess
(uff)
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
