From: Ramsey L. G. <rg...@ma...> - 2009-12-13 22:24:35
|
A lot of these @keys seem to be pretty broken. I'm working on fixes for them, but if people are using the broken behavior, well... changing them to work 'correctly' is going to break current implementations :-/ For instance, @unique calls contents() first, then uniques... so if you have a path key1.@unique1.key2.@unique2 it appears that then becomes key1.key2.@unique2.@unique1 as far as execution order goes. Flatten does the same thing even though the documentation seems pretty clear that these should apply to the left side of the @key. The ambiguously documented @reverse actually applies to the left when you might think that one goes right. Even the contains() method is too restrictive on the return type. Using an @flatten with an @sum like employees.paychecks.@flatten.@sum.amount gives you a ClassCastException because contains() tries to cast the BigDecimal sum into an array. Fetchspec assumes everything after @fetchspec is part of the fetchspec name eliminating the possiblity of doing something like @fetchspec.fetchspecName.morePath. So does the SortOperator, but in that case, I'm not sure whether that should be considered a feature or a bug. If left as is, then you could not do something like @sort.firstName,lastName.morePath, but if changed, you can no longer do @sort.firstName.length,lastName. Whatever it is going to be, it needs to be clearly documented which one it is. So, anyway, I'm posting because I'm wondering how many people are actually using sort @key operators. Are you using keypaths in the sort orderings? I suppose the safest way to go is to change that one as little as possible. That does limit @sort to the end of the keypath and limits it to one per keypath, but I can see how a sort keypath can be useful too. Any thoughts? Ramsey On Sep 23, 2009, at 7:28 AM, Anjo Krank wrote: > Well... actually, the docs stated that > > * > <code>myArray.valueForKeyPath("@removeNullValues.someOtherPath");</ > code><br/> > * Which in this case would return myArray without the > occurrences of NSKeyValueCoding.Null. > > So *if* the current behaviour is to return the persons with no office, > it's correct. If not, you can rollback this change, as I don't use it > anyway. > > You should be able to write your query like > >> @unique.@removeNullValues.office > > > Which makes more sense when you think about it. > > Cheers, Anjo > > > > Am 23.09.2009 um 12:33 schrieb Michael Shkutkov: > >> Unfortunately your commit broke our projects. >> >> We have key path "@removeNullValues.@unique" which doesn't return >> correct results now... >> >> Actually I always thought that "persons@removeNullValues.office" >> should return array of offices for non-null persons, but not array >> of persons with non-null relationship. >> >> As for David's problem I guess the best solution is method in java... >> >> >> On Mon, Sep 21, 2009 at 10:45 PM, Anjo Krank <an...@kr...> wrote: >> dunno who wrote it, but try to update and see if it now works. btw: i >> hope your officeID is public... >> >> Cheers, Anjo >> >> >> >> Am 21.09.2009 um 20:24 schrieb David Holt: >> >>> Can someone enlighten me as to how this works? I tried the following >>> in a WORepetition as the list binding thinking that it would remove >>> the people from the list with null values for the officeID. >>> >>> <wo:WORepetition list = >>> "$personDisplayGroup.displayedObjects.@removeNullValues.officeID" >>> item = "$aPerson"> >>> >>> which resulted in: >>> >>> java.lang.IllegalArgumentException: While trying to invoke the set >>> method "public void ca.cscw.ctcma.components.PersonList.setAPerson >>> (ca.client.model.Person)" on an object of type >>> ca.client.components.PersonList we received an argument of type >>> java.lang.String. This often happens if you forget to use a >> formatter. >>> >>> So the list binding is returning a string, which makes sense given >>> that the last value in the keyPath is a string. How do I remove >>> people from the array that don't have an officeID or am I missing >>> the point of this Array Operator entirely? >>> >>> Thanks, >>> >>> David >>> >> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® Developer Conference in >> SF, CA >>> is the only developer event you need to attend this year. Jumpstart >>> your >>> developing skills, take BlackBerry mobile applications to market and >>> stay >>> ahead of the curve. Join us from November 9-12, 2009. Register >>> now! >>> http://p.sf.net/sfu/devconf_______________________________________________ >>> Wonder-disc mailing list >>> Won...@li... >>> https://lists.sourceforge.net/lists/listinfo/wonder-disc >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart >> your >> developing skills, take BlackBerry mobile applications to market and >> stay >> ahead of the curve. Join us from November 9-12, 2009. Register >> now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Wonder-disc mailing list >> Won...@li... >> https://lists.sourceforge.net/lists/listinfo/wonder-disc >> >> >> >> -- >> Cheers, Michael > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Wonder-disc mailing list > Won...@li... > https://lists.sourceforge.net/lists/listinfo/wonder-disc |