Re: [Xaraya_bk-notices] Re: 1 cset was pushed to core/stable: admin-validation-subform.xd: Change to ...

Michael Cortez wrote:
> ...
> Man that was a beast of a property to figure out.  Took me 6hrs to get that
> far, because the first DD Object that I created didn't have an Item ID
> field.
> 
Heh - sorry about all that. I built subform with certain sample cases in
mind, and was planning on generalising / tweaking it further when I got
some time to concentrate on some tricky parts. If it's any consolation,
you and MrB are probably the only ones who've really got it working so
far :-)

> The second one had an Item ID field, but I didn't name it 'itemid'
> 
> What this resulted in, was multiple dd items for my object with the same
> id's.  Which meant that the db calls bringing those items out from the db
> were getting multiple records, when they really should have been getting one
> record back.
>
I don't remember the requirement for calling an Item ID field 'itemid'
though. If you're talking about the 'itemid' style, the argument
'itemid' => $value should retrieve the one item with that item id
regardless of how it's called.

And on creation of the item, whatever itemid is needed should be
automatically created by DD and filled into the right field.

Are you sure you didn't accidently create items with the same id
while you were tweaking the code / templates ? That's one of the
tricky parts, to ensure that it does behave properly with what
DD is expecting on input for item creation.

So yes, if you somehow managed to by-pass the restrictions and
create items with the same id, then you may get more than one
item back afterwards. But it shouldn't have happened with the
original code / templates - at least from the tests I did with
my sample cases. Your mileage may vary :-)

> I had assumed, that somewhere, deep down (perhaps with a primary key on the
> DD Data table) there was something to prevent multiple DD Items with the
> same id.
> 
Depends on the arguments passed - if the itemid is filled in, and you
still want to create it, that's allowed by DD because it may be needed
in some cases. And there's no check against duplicate entries on
creation if you use the xar_dynamic_data table as data store, so yes,
it's possible to end up with more than one item with the same id if
you don't give DD the right input arguments.

Which is why those templates are a bit tricky - if you accidently have
a value in the itemid field when creating an item, then conflicts might
appear down the line.

For objects stored in dedicated tables, the primary key will ensure that
you don't get items with duplicate item ids, but there's no such
guarantee for xar_dynamic_data - so garbage in, garbage out applies :-)

> I hope to have time this week to also post a quick how to for the other two
> modes.
>
Great - thanks.

> I'm still not quite sure what the point was of having a selectable link (in
> the child style) w/o also having a selectable display title field.
>
I don't remember the details, but it could simply be work in progress
that fitted my immediate needs and needed to be extended later on.

> The child style still needs a way to delete children, and to link in other
> children that have been defined by the same object but by different
> properties (or already exist in the DD Object from importation or other
> sources.)
>
Passing information across properties is still very tricky at the
moment. The code in comments that I had using $this->_itemid for
// CHECKME: set the value to the itemid by default for childlist ?
is one example where I had to extend DD to support this kind of
operation, but using some other property value as "parent value"
would be rather ... difficult at this time.

I'm not sure I understand what you mean by your last sentence though.
Do you mean link children through more than one child property ?

Mike.