Bug #1620

Reference array keys are discarded during persistence without a warning

Added by Robert Lemke over 10 years ago. Updated about 8 years ago.

Status:
Resolved
Priority:
Must have
Category:
FLOW3 Persistence
Target version:
-
Start date:
2008-10-01
Due date:
% Done:

100%


Description

@reference properties of type array (ie. references to other objects) are persisted - but only the values. The keys of this array are discarded. Either implement support for persisting these keys as well (would be very cool) or at least throw a warning in the meantime if the array keys are something else than integers.

Nodetree-from-objects.png View - Two arrays stored as a node structure (43.1 KB) Karsten Dambekalns, 2008-11-26 17:39

Associated revisions

Revision f172bffa (diff)
Added by Karsten Dambekalns over 10 years ago

FLOW3, TYPO3CR:
  • the persistence framework no longer needs the @reference annotation, fixes #1620
TYPO3:
  • removed @reference annotations

Revision 61aa7621 (diff)
Added by Karsten Dambekalns over 10 years ago

FLOW3, TYPO3CR:
  • Persistence: rewrote the way object trees are stored in the CR, fixes #1883, fixes #1882
TYPO3CR:
  • Persistence: array keys are now preserved when persisting, fixes #1620
  • Persistence: fixed error when persisting DateTime properties, fixes #2195
  • changed the way properties are added to the Lucene index, fixes #1623, refs #1886
  • fixed storage backend to enable use of namespaced nodetype names
Lucene, TYPO3CR:
  • moved the KeywordAnalyser here from TYPO3CR

History

#1 Updated by Karsten Dambekalns over 10 years ago

  • Priority changed from Should have to Must have
  • Target version set to 1.0 alpha 1

#2 Updated by Karsten Dambekalns over 10 years ago

  • Status changed from New to Accepted

#3 Updated by Karsten Dambekalns over 10 years ago

A warning is probably not be what people would like to see...

Anyway, JSR-283 (as well as JSR-170) only support array-like multi-valued properties, and arrays simply do not have "named keys" in Java; a hashmap is used for that instead. Thus we need to store those "associative arrays" differently. One way could be:

N flow3:someobjectinstance [flow:]
  P name = cool
  P foo = bar
  P scores = [1, 3, 2, 6, 1, 1]
  N members [AssociativeMultiValuedProperty]
    P foo = bar
    P lame = duck
    P another = item

Legend: N = node, P = property, [something] = node type

for an object having two simple properties, one numerically indexed array and one associative array.

There is still an open question: what about numerically indexed arrays whose keys are "used", i.e. carry meaning? It is impossible to detect those, so maybe we need another annotation (e.g. @preservekeys)?

#4 Updated by Robert Lemke over 10 years ago

Karsten Dambekalns wrote:

There is still an open question: what about numerically indexed arrays whose keys are "used", i.e. carry meaning? It is impossible to detect those, so maybe we need another annotation (e.g. @preservekeys)?

That's difficult ... If in doubt I would look at what the user would expect to happen: If she doesn't know about the special annotation, she would be surprised to find out that all keys are gone.

BTW, interesting in this regard is also the planned SplFastArray: http://www.colder.ch/news/06-07-2008/33/splfastarray-to-speed-up-.html

#5 Updated by Karsten Dambekalns over 10 years ago

If people would jump on the SplFastArray wagon, that would make life easier. We could store SplFastArray as simple multi-valued properties, and regular arrays using the more complicated construct proposed above.

Still I would like to avoid using that construct more than needed, as it smells of performance loss. Hm, I guess I shoud try that and actually measure...

#6 Updated by Karsten Dambekalns over 10 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100

Applied in changeset r1500.

#7 Updated by Karsten Dambekalns over 10 years ago

  • Status changed from Resolved to Accepted
  • % Done changed from 100 to 0

Used the wrong issue number in the commit message...

#8 Updated by Karsten Dambekalns over 10 years ago

  • Project changed from TYPO3.Flow to TYPO3.TYPO3CR
  • Category deleted (Persistence)
  • Target version deleted (1.0 alpha 1)

#9 Updated by Karsten Dambekalns over 10 years ago

  • Category set to FLOW3 Persistence
  • Target version set to 197

#10 Updated by Karsten Dambekalns over 10 years ago

  • % Done changed from 0 to 70

Locally I have now implemented storing all arrays as nodes (of nodetype flow3:arrayProxyNode), this will solve the issue and make array keys "first class citizens" again.

This will be committed into SVN as soon as the related changes for #1883 are stabilized.

#12 Updated by Karsten Dambekalns over 10 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 70 to 100

Applied in changeset r1565.

#13 Updated by Robert Lemke about 8 years ago

  • Target version deleted (197)

Also available in: Atom PDF