Opened 14 years ago

Closed 13 years ago

#6508 closed defect (invalid)

Why does _itemsByIdentity loop thru _arrayOfAllItems?

Reported by: guest Owned by: Jared Jurkiewicz
Priority: high Milestone:
Component: Data Version: 1.1.0
Keywords: Cc:
Blocked By: Blocking:


I posted to the mailing list 2/20, but I still think this looks like a problem. in ItemFileReadStore? line 493, it loops thru _arrayOfAllItems and I think it should be _arrayOfTopLevelItems. Why should it look for identifier in embedded objects. Is it logical to think that embedded objects would also have the same identifier?

Al Byers [email protected]

Attachments (1)

programaticGridNestedAttr.htm (4.1 KB) - added by yaz_k83 13 years ago.
Demo to reproduce issue.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 14 years ago by bill

Component: GeneralData
Owner: changed from anonymous to Jared Jurkiewicz

I don't see any reason to exclude items, but passing to Jared so he can answer directly.

comment:2 Changed 14 years ago by bill

PS: meant to say "exclude *nested* items"

comment:3 Changed 14 years ago by Jared Jurkiewicz

Resolution: invalid
Status: newclosed

Every item has a unique identifier, not just top level items. When you request by identifier, you are asking to locate a very specific item. It may be nested, or it may not, and therefore it searches all items, not just root level ones.

Changed 13 years ago by yaz_k83

Demo to reproduce issue.

comment:4 Changed 13 years ago by yaz_k83

Resolution: invalid
Status: closedreopened

Hi Jared,

I have come across a similar (perhaps the same) issue as raised by a guest above...

The issue is as follows:

  1. When I have a nested object I am unable to use identifier.
  2. If I use identifier field it expects the same to be used for the nested objects as well.

Now if I have details of students... with details like roll, name, marks, joiningDate (nested object with day, month, and year), etc; and roll no is the identifier, even nested fields like joining date need to have roll no. else the grid does NOT render itself.

I am attaching an HTML test file along, please try out the following...

  1. run it as is... it should work.
  2. Uncomment line no. 53 [identifier: 'roll',]; Now the code wont work... check fire bug for error message. you will see - [TypeError: arrayOfValues has no properties message=arrayOfValues has no properties].

3 now uncomment the commented section of the joiningDate nested object from line no. 57 to 63 [roll: 10, ] - Now the code works..

This is a defect since identifier should be applicable only to the topmost level object and NOT to all the nested objects. Thank you.

Regards, Yazad Khambata

comment:5 in reply to:  description Changed 13 years ago by yaz_k83

Kindly add me to the cc list for this ticket: [email protected]

comment:6 Changed 13 years ago by Jared Jurkiewicz

Resolution: fixed
Status: reopenedclosed

The store behaves as expected and as defined by its documentation. Every data item *must* have a unique identifier. Regardless of how it is nested. The fetchByIdentity() API makes no distinction between a nested item and a top level item in the data tree.

I repeat, this is not a bug in the store. If you have nested items, they too must have unique identifiers to they can be looked up directly, same as a top-level item.

comment:7 Changed 13 years ago by Jared Jurkiewicz

If you want to treat complex values as non-items with ItemFile?*Store (IE, they are not Items from the perspective of ItemFile?*Store) and are not bound by the identity requirement, then you can do that through the custom type map capability of ItemFile?*Store.

CustomType? maps are a way to tell ItemFile?*Store that a value of a particular attribute is in itself not a unique data store item, but just a value, same as a string, int, boolean, etc.



If you still want those nested fields to be treated as items and they can't have roll no, then roll no can't be used as the 'identifier'. You could, in fact, not assign any attribute as an identifier (leave off the identifier field from your dataset), and ItemFile?*Store will assign its own identifiers to your data that are not based off public fields (Effectively just the index count of the array of items). That way you're also guaranteed not to collide.

Which is, incidentally, why commenting out identifier works for you in this case. The store auto-assigned some for you.

Those are the options you have for ItemFile?*Store:

1.) Apply identifier attribute that is unique to ALL JavaScript? objects in the data you are passing as data store items.


2.) Don't assign an attribute the role of identifier and let the store auto-assign unique ones.


3.) Use a custom type map to make the ItemFile?*Store treat the joining field value as a straight value and not a data store item.

comment:8 Changed 13 years ago by Jared Jurkiewicz

Resolution: fixed
Status: closedreopened
Note: See TracTickets for help on using tickets.