We'll officially switch to the list now :) I just did it again ...
> From the Bug report:
> > 1. PropertyListComparator. It can only handle keys of the same
> type, and throws exception if the keys are not the same and/or the
> keys are not of one of the hardcoded types. We need something more
> generic that can gracefully handle any kind of key
>
> Sure. For the eomodels I didn't need it yet, and it didn't seem
> obvious how to do it, so I just left the Exception in and decided
> to do it when I hit that exception.
> I took a quick glance at your code. It seems you are comparing
> toString() when everything else fails. I'm not sure if the compare
> algorith is still stable (from a<b and b<c it has to follow a<c). I
> introduced a similar bug when I put in the special case for
> comparing the "name" key first, and then the rest of the keys.
This is a good point ... I'm not sure if it will be stable either.
Worst case is that it gets randomized, though. But in most cases, if
the toStrings aren't comparable, there's probably not an obvious
comparator you could use anyway.
> > 2. Sorting a list seems wrong - list is not a random order data
> structure
>
> Yep. Unfortunately it didn't make much sense do not sort lists (as
> I wrote in my other email). The question is, which lists are
> semantically sets, and which aren't. I don't know a real solution
> to this.
Yeah. The new API has a ParserDataStructureFactory that has an
interface like:
Collection createCollection(String keyPath)
Map createMap(String keyPath)
where keyPath would equal "root.connectionDictionary.jdbc2Info.BIT".
So in createCollection, we could look for paths that we KNOW we want
to be sorted (like root.entities) and return TreeSet(..) vs List.
> > 3. PropertyListComparator comparing Maps is probably added to
> handle case (2). By itself it seems redundant and wrong.
>
> Don't know what this is supposed to mean. I wanted to compare two
> dictionaries so their "name" key is handled first, and if that
> fails, their sorted keys and values are compared.
Yeah I wasn't really sure what this one meant either. I sort of
ignored it in my response to him as well.
>> So basically the disagreements he had were related to the code
>> being a little too specialized, which is kind of true -- it was
>> obviously designed with EOModel plists in mind. It also was
>> discussed whether sorting when writing was correct, or whether it
>> should just preserve whatever order the model presents it with.
>> As a result, I switched things around and redesigned how the
>> plists are READ.
>>
>
> My goal was that all emodel files are always in normalized form.
> When you only sort when reading, but not when eg. manipulating with
> the EOModel editor, you would get an unsorted file on write? That
> shouldn't be the case.
You mention it below, but basically the actual Map impl that you get
back is sorted, so it preserves sort throughout.
> Ah. If you are using TreeMap, my last remark does not apply of course.
>
> Btw, what comparator does TreeMap use? How does it compare Maps
> (dictionaries) as keys?
You can construct it with a Comparator. I use the one you sent me
for it (well, the variation-on-a-theme of the one you sent me).
>> This also means that the PropertyListComparator moves into
>> EOModeler and out of Cayenne, so it's OK then that it is a little
>> more specialized. I did end up adding support for comparing
>> incompatible types, though, because UserInfo can actually have a
>> mix of String and Number keys (as an example). So the basic
>> change is that the plist when loaded out of the is actually sorted
>> according to your rules, and when I write it, it just writes in
>> the natural order of the Map it's given (which happens now to be
>> sorted).
>>
>
> That sounds fine. Except I don't understand where
> PropertyListComparator is being used now, as you are using TreeMap
> now.
see above ...
> So two problems remain. What to do about lists (to sort or not to
> sort), and how to have a stable comparison between different types
> of objects.
I'll add a debug println and we can see all the collections that
appear when parsing, and we can pick out the ones that should be
sorted and the ones that shouldn't.
> Marc
ms :)
This archive was generated by hypermail 2.0.0 : Tue Jul 18 2006 - 09:25:27 EDT