i4o Work Item Rss Feed

Commented Issue: Using Union and Intersect in WhereThroughIndex in i4o v2 [19925]

Gregory1981 — Tue, 15 Feb 2011 16:47:21 GMT

In v2 branch in WhereThroughIndex results from different indexes are combined using Union and Intersect. However Union and Intersect, while operating on IEnumerable interface, are set operations. They return sets, and because of that they remove duplicates. So, there's a bug: if original sequence contains duplicates, result returned from WhereThroughIndex with complex query is not.
Comments: ** Comment from web user: Gregory1981 **

The issue is that WhereThroughIndex sometimes returns duplicates and sometimes not, which is inconsistent and confusing.
Here it is:

[Test]
public void SuperComplexQueryWithDuplicates()
{

var single = new SimpleClass { Name = "Jason Jarett", Age = 25, FavoriteColor = Color.Aqua };
SimpleClass[] someItems = {
single,
single,
single,
single
};
var indexSpec = IndexSpecification<SimpleClass>.Build()
.With(person => person.FavoriteColor)
.And(person => person.Age)
.And(person => person.Name);
var theIndexSet = new IndexSet<SimpleClass>(someItems, indexSpec);
var result =
from item in theIndexSet
where item.Name == "Jason Jarett" && item.Age == 25 && item.FavoriteColor == Color.Aqua
select item;
Assert.AreEqual(4, result.Count());
}

Commented Issue: Using Union and Intersect in WhereThroughIndex in i4o v2 [19925]

staxmanade — Tue, 15 Feb 2011 05:24:12 GMT

I'm struggling to see what your issues is. Any you can produce a test?

Created Issue: Using Union and Intersect in WhereThroughIndex in i4o v2 [19925]

Gregory1981 — Sun, 06 Feb 2011 14:46:46 GMT

In v2 branch WhereThroughIndex results from different indexes are combined with Union and Intersect. However Union and Intersect, while operating on IEnumerable interface, are set operations. They return sets, and because of that they remove duplicates. So, there's a bug: if original sequence contains duplicates, result returned from WhereThroughIndex with complex query is not.

Created Issue: IndexableCollection.Clear performance [16698]

vaso — Wed, 10 Mar 2010 02:32:44 GMT

As described in this discussion: http://i4o.codeplex.com/Thread/View.aspx?ThreadId=204383,
when deleting items from a list one by one, it should be done at the end of the list, otherwise unnecessary copying occurs.

Commented Issue: Reflect property changes in index for classes that support INotifyChanging and INotifyChanged

staxmanade — Fri, 07 Aug 2009 05:52:00 GMT

Hi,

I greatly like this library, but to be able to use it in one of my projects, I need support for propertychanges to items in the IndexableCollection. Ideal would be to automatically update indexed properties of classes that implement INotifyPropertyChanged and INotifyPropertyChanging.

I'll try to submit a patch which implements just that.
Comments:

Lashas

Great suggestion. It's funny how I didn't notice that. By using the C# syntactic sugar (where we don't specify "prop += new EventHandler(Handler)" and instead use "prop += Handler") I didn't even think about it haveing to create a new object for each pass...

Thanks for the contribution.

Commented Issue: Reflect property changes in index for classes that support INotifyChanging and INotifyChanged

staxmanade — Fri, 07 Aug 2009 05:45:16 GMT

Test comment from V.S. /tfs since I can't hit the codeplex website.

Commented Issue: Reflect property changes in index for classes that support INotifyChanging and INotifyChanged

Lashas — Thu, 06 Aug 2009 23:12:40 GMT

Hi,
I have optimizied a littile bit (adding item to list is ~30-40% faster) by changing how handlers are attached to item. Instead of
(item as INotifyPropertyChanged).PropertyChanged += IndexableCollection_PropertyChanged;
I've changed to
(item as INotifyPropertyChanged).PropertyChanged += _propertyChangedHandler;
while _propertyChangedHandler is private field in IndexableCollection, and is initialized in constructor by this line "
_propertyChangedHandler = new PropertyChangedEventHandler(IndexableCollection_PropertyChanged);"

Finally this left me with same performance as object would be without INotifyPropertyChanged interface.

Reopened Issue: Reflect property changes in index for classes that support INotifyChanging and INotifyChanged

staxmanade — Sat, 25 Apr 2009 21:52:21 GMT

Commented Issue: Reflect property changes in index for classes that support INotifyChanging and INotifyChanged

staxmanade — Sat, 25 Apr 2009 21:38:04 GMT

Thanks for the patch...

I've created a branch, checked in your changes (to the branch), and added one test and fix for the case when a raised property changed event throws a bad property name.

I would like to spend some more time thinking about this change and other side affects it may cause. (performance, etc) before it is merged in, however this is one of the big ticket items Aaron and I both feel the library should support.

Thanks again,
Jason (Staxmanade)

Closed Issue: Reflect property changes in index for classes that support INotifyChanging and INotifyChanged

staxmanade — Sat, 25 Apr 2009 21:35:06 GMT

Created Issue: Reflect property changes in index for classes that support INotifyChanging and INotifyChanged

lukdereu — Sat, 25 Apr 2009 17:01:45 GMT

CLOSED FEATURE: Thread Safety

ericksoa — Sun, 08 Jun 2008 21:54:49 GMT

The io4 library uses generic dictionaries which are not thread safe.
Comments: Will not fix. Most .NET collections are not thread safe, this one included.

CLOSED ISSUE: Indexing on Strings in VB

ericksoa — Sun, 08 Jun 2008 21:54:07 GMT

A strange thing happened during my demo prep for TechEd 2008. After Julie Lerman gave me a ration for not having enough VB, I decided to make one of my demos based on VB. I discovered, of course, that VB has a different convention when a string comparison ends up in an expression. Right now, string comparison does not take advantage of indexing in VB.

That said, I have fixed the issue, and should have it back to codeplex sometime this weekend.
Comments: fixed as of 0.91

CREATED ISSUE: Indexing on Strings in VB

ericksoa — Sat, 07 Jun 2008 04:05:17 GMT

COMMENTED ISSUE: Thread Safety

ericksoa — Fri, 23 May 2008 02:05:51 GMT

The io4 library uses generic dictionaries which are not thread safe.
Comments: ** Comment from web user: ericksoa **

True enough. Most of the .net framework isn't in that category either - up to and including generic dictionaries. Personally, if I want to be threadsafe, I am going to use F# and stick to immutables, but thats just me :)

CREATED ISSUE: Thread Safety

SMHoff — Fri, 14 Dec 2007 14:21:11 GMT

The io4 library uses generic dictionaries which are not thread safe.