This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello, Almost every system I work on has some sort of reporting, or charting requirement. An example may include showing a chart as to how many people have signedup per hour for the past day, or how many people have signed up per day for the past year. There seems to be several. So I ended writing something like this to report the number of parties (aka people, companies) who registered today, summarized by the hour. public static Models.Item[] Today(this IQueryable<Party> model)
I'd like to refactor this to something like this:
public static Models.Item[] Today<T>(this IQueryable<T> model)
However, this will not compile because CreatedOn doesn't necessarily exist on T. This raises two questions. Can I rewrite this query using LightSpeed such that it will compile? Is there a better approach to summarize information such as this using LightSpeed? I'm curious whether other people have similiar requirements and whether this would be a useful addition to a future version of LightSpeed. Thanks, Werner |
|
|
I think the limitation you're seeing is in the .NET generics type system, rather than in LightSpeed. From LightSpeed's point of view, what you're doing is fine; it's C# that frets about the CreatedOn field. You can probably work around this by either: (a) declaring CreatedOn in an abstract base class (using concrete table inheritance because you don't want to share tables and you won't be loading the items polymorphically); or (b) creating an interface containing CreatedOn, and declaring through the partial class that each of your entities implements that interface. Then you can use a type constraint on T: in the first class where T : TrackedEntity, in the second case where T : Entity, ITracked. That should be enough to reassure the compiler that CreatedOn necessarily exists on T and you should then be good to go. Thanks for feature suggestion. We've considered some sort of reporting/aggregation capability but for the time being we're not sure what we would offer to compete with existing reporting platforms -- we'll keep thinking about it though! |
|
|
Oh, by the way, another option is to use query objects instead of LINQ. Attributes specified in query objects (such as Entity.Attribute("CreatedOn")) are not checked by the compiler, which is sometimes a bad thing but in this case would be a good thing! |
|
|
That is what I was looking for. Not sure I want to use inheritance to solve this problem. Thanks, Werner |
|