Help /w Partial Classes to set [Indexable] attribute

Help /w Partial Classes to set [Indexable] attribute

Old forum URL: forums.lhotka.net/forums/t/5825.aspx


Jack posted on Tuesday, November 18, 2008

I'm using codeGen to produce my properyInfo types and want to start adding some [Indexable] attributes to some of them.  Can I do this somehow with partial classes or do I need to update my CodeGen template to handle that.

Can I use a method call to replicate the [Indexable] attribute in the non generated partial class?

Thanks

jack

RockfordLhotka replied on Tuesday, November 18, 2008

I don't believe there's an alternative to the attribute, so you will probably need to update your templates.

Jack replied on Wednesday, November 19, 2008

I really don't know too much about how attributes work (other than the google I did last night) but if you had the time:

1) What is the advantage of using an attribute over just implementing the IndexableAttribute as a member of PropertyInfo?  Doesn't it just lock you in to setting features/options at compile time?

2) Would this be something that could be tweaked to allow the index to be added at runtime or on the fly?  I could see using and index at the beginning of an initialization process to setup children etc and then never needed again.  It could then be dropped.  I looked through the BusinessListBase where the indexed fields are gathered (IndexSet()  the calls to PropertyInfo.GetCustomAttributes()) and it seemed to me that it wouldn't be a stretch to tweak that to use a member of the ProperyInfo vs. extracting the attributes.

Please note I'm certainly not 'complaining' or anything, just trying to understand/learn the implementation, the reasoning behind it and how I can best use it.

Thanks

jack

 

RockfordLhotka replied on Wednesday, November 19, 2008

I’m not entirely sure you understand the goal of indexing.

 

Indexing is for use with LINQ to CSLA only. Indexing is only useful if you load a collection into memory and then do many queries against that same collection, and with a WHERE clause that uses only the indexed property.

 

If you are not doing many queries against the same collection using a WHERE clause that only uses the indexed property, then using the Indexable attribute will be a total negative for you.

 

Good (if done many times against the same collection):

var q = from r in myList where r.IndexedProperty > 100 select r;

 

Bad (if done just one or two times against the same collection):

var q = from r in myList where r.IndexedProperty > 100 select r;

 

Bad:

var q = from r in myList where r.IndexedProperty > 100 && r.OtherProperty < 1000 select r;

 

The reason for the “bad” is that creating and maintaining an in-memory index isn’t free. In fact, it is quite expensive. So it is only a good thing to do if you can use the index multiple times to recoup the cost of its creation.

 

Rocky

 

Jack replied on Wednesday, November 19, 2008

Rocky,

I fully understand the goal of indexing and know exactly where and when I'm going to use it. I'm foremost a database guy so I'm just curious about the implementation and trying to learn why you did it one way vs. the other.  Also since I'm struggling already with the implementing of CodeGen learning curve (hence the original question) and CSLA learning curve I'm trying to resolve everything in my head at once :-)

My last post/question was more about why use an attribute vs. not.

I then had an earlier unanswered post about when exactly the index was rebuilt.  If it is so 'expensive' to maintain then why make it so limiting to turn on/off. 

I can see a few different scenarios that use the indexes in different ways:

1) I'm loading in a complex set of BO's with related data that I can load a mass amount of data on my big fast powerful server, turn on indexing, do my processing, sorting, linking, querying of data, and then serialize everything, send it to the client, and never need the indexes again

2) On my client side I have a number of filtered views of the data - master/detail.  Everytime the user changes the master I want to show a filtered set of detail data and will have numerous different filters within that set as well.  Indexes are perfect here.  However when it comes time to save the data I don't care about the indexes.  I want to send the data back to the server to be saved.  I don't need the index on the server or the time to rebuild it.

3) I have some large data transformations I need to do (essentially transposing columns to rows) that I can do in the database in some instances but in a high workload scenario I would rather pass that to the client and let it churn on his box not mine.

Anyhow just some thoughts - I'm very excited about the feature and I appreciate your time.

RockfordLhotka replied on Wednesday, November 19, 2008

CSLA is designed to support the idea of objects designed based on use cases, not data.

 

If your use case involves retrieving a list of data and doing numerous lookups into that list, then indexing should be used in the object(s) that support that use case.

 

If your use case doesn’t involve doing numerous lookups into a list, then indexing should not be used.

 

At least this is the thought process behind nearly everything in CSLA, including the LINQ to CSLA design.

 

It may help if I answer your other question about when indexes are created. They are created on-demand. If you don’t do a L2C query that uses an index, the index is never created.

 

So I think we support your scenarios. If you do queries on the server and return the objects to the client, and the client doesn’t do queries, then the index would only get created on the server. Or if you load the objects on the server, return them to the client and only do queries on the client, then the index would only get created on the client.

 

Chapter 14 in the Expert 2008 Business Objects book is all about the LINQ to CSLA implementation – both indexing and synced query results. It should answer many of your questions.

 

Rocky

Jack replied on Wednesday, November 19, 2008

Thank you - that clears up a lot. 

I think what wasn't clear or that I missed from the Alpha Chapter 14 is that the create on-demand is reset with each serialized trip.  I sort of assumed that if I used it once and it was created, then it would be re-created with each trip because it has be created at least once.  In fact it is almost the opposite - if I serialize the BO then I essentially drop the index and have to incure the cost to rebuild it again if I want to use it.

That is good to know

thank you

jack

 

RockfordLhotka replied on Wednesday, November 19, 2008

Right, the index won’t go across the wire. Going across the wire is expensive, so I try to minimize what goes across. It is almost always cheaper to recreate structures on either side than to move them.

 

So things like validation/business rule associations, authorization rules, and indexes do not serialize.

 

Things that are directly part of the object’s state or meta-state like data fields, state fields (IsNew, etc) and currently broken rules do serialize, because they can’t be recreated on the other side.

 

Rocky

Copyright (c) Marimer LLC