I didn't find anywhere whether is possible to query from Db4o all objects implementing some generic interface
for example:
to query all objects implementing IList<T>, I tried:
var items = from IList<object> item in session
select item;
but this doesn't return all lists in database (only the ones which implements specificaly IList<object>)
Is there any way to do it other then query all objects from database, loop them and evaluate the object manually? (I would have to pass through milions of objects in this case)
Thank you
You want to query for all objects which are any instance of the IList<> type. Or other costume generic types.
In my opinion this is not possible at the moment. The reason is that db4o treats each instance of a List<> as its own type. So a List and a List are stored a two different types. This goes right down to the meta data storage in db4o, where those are stored separately. This also means that there not shared index for all instance of the different List<> types.
Btw in Java it is the other way around, all types of List<> are treated as the same type, since in Java generics are not reflected at runtime.
So, you basically need to go over all the different types of List<> yourself to get all instances.
For your own types I would create an abstract non generic class which the generic instance inherit. Then you can query for that and get all generic subtypes. Note that this doesn't work for interfaces, since db4o doesn't index or keep meta-infos for interfaces.
Related
I have a design right now where I want a dictionary that gives me some values that could be of different types. My idea would be to have some interface that would represent a potential value type so then I could implement the interface. My problem is that if I make a generic interface then I can't have the dictionary return multiple types of the interface. If I make variable interface methods, then I can't implement them properly in the wrapper classes. Does anyone have a good solution to have a dictionary with variable value types?
I am making a library which is going to be used widely by different applications. You can say that it is sort of a public library or SDK.
Currently I am working on a function which takes a list of Points performs some calculation on these points and then return list of updated points. So my question here is what should I use as return type and in my parameters. IList, IEnumerable or Collection.
So here it the function. I am unaware what user will do with the output. How user uses it, is on him. So what should be best option to use here.
public static IEnumerable<Point2D> PeformSomeCalculation(IEnumerable<Point2D> points)
{
// Do something,
return updatedPoints;
}
The IList<T> interface inherits from ICollection<T>, IEnumerable<T> and IEnumerable.
So if you return an IList<T>, clients that want an ICollection<T>, an IEnumerable<T> or just an IEnumerable will all be happy.
Do you want the points collection to be manipulated?
If so use ICollection or an IList as these expose Add, Clear and Remove methods.
If you need the list to be indexed then you should choose IList - this interface inherits from ICollection and IEnumerable so this may be what you are after.
If you do not require the collection to be modified or indexed then use IEnumerable.
As a parameter you should use the most specific required type. It's mean if you need in function only functionality of IEnumarable you should use IEnumarable, not ICollection or IList.
And as a return type you should use the most general type, but you should be aware for ICollection and IList type. If you use this in Linq to SQL - this function has method contains but Linq cannot translate this function in this type to SQL.
Generally I would try not to build assumptions into what the user will do, unless I am trying to enforce a rule such as this collection is read only, so I would use the most general type. Also you may consider implementing an iterator, as you are accepting a list and returning an updated list.
Making use of the yield return statement may be convenient for your clients allowing them ForEach functionality. Simple to implement.
How to assign same object list but in different namespace.
list, list2
list = list2;
Cannot implicitly convert type
System.Collections.Generic.List<namespace1.MyData> to System.Collections.Generic.List<namespace2.MyData>
This sounds to me like a WCF proxy that has been generated and you want to reuse the existing class libraries instead of the proxy generated ones.
If this is the case, then see this answer or this answer.
Edit:
as a follow up to this, occassionally you may be in the position where you can't reuse the common class definitions (in the case of Silverlight you have to create a whole new assembly which may not be practical). If you are in this position, there is another option: the proxy generated classes are defined as partial, so you can extend them with a Clone() or Copy() method that returns the identical object from the other namespace, with the values copied over.
If the objects can be cast to each other, you can do this, but it is looping though the lists and making a copy, it's not a direct assignment.
var newList = oldList.Cast<NewType>().ToList();
One example of the general case:
public class Validator
{
// ...
public ReadOnlyCollection<InvalidContainer> ContainersUnderMinimum
{
get { return _containersUnderMinimum.AsReadOnly(); }
}
}
public class InvalidContainer
{
// ...
public int LowestVolume { get; set; }
}
The Validator class above takes a collection of other items in its constructor, then adds invalid items to the internal List. Each container has many sub-containers (think a rack of test tubes), and the class wants to find the lowest volume. The constructor is adding to the list when an item (tube) is not found, and updating the existing list object when an item is found.
The problem is that the Validator wants to return a read-only collection of immutable objects, but the objects (InvalidContainers) must be mutable post-construction so that values can be (essentially) accumulated.
Refactoring to use an interface (IInvalidContainer) causes headaches, as generic collections cannot be cast to collections of a base type.
What are some good patterns or practices to solve this issue?
EDIT: To clarify, the intention is to have the property value (the collection) be immutable. I understand that ReadOnlyCollection only enforces immutability of the collection, not of the collection items. Normally I would make the items immutable, but I can't in this (and similar) cases. However, I only want the items mutated at the time the Validator class is being constructed. Preventing callers from doing unwise casting is not a design goal; the goal is to avoid tempting callers with a settable public property.
EDIT: Changed the title for clarity.
EDIT: Here's the refactored version (based on suggestions from LBushkin and recursive):
public IEnumerable<IInvalidContainer> ContainersUnderMinimum
{
get
{
return _containersUnderMinimum.Cast<IInvalidContainer>();
}
}
If I understand your problem correctly, you want to return a collection of immutable types, but internally retain a mutable collection. The typical way of doing so, is to create a base type (or interface) for your type that is immutable and return that.
You can either cast items to that type (a weak form of immutability control), or you can create wrapper objects and return those (a strong type of control). Wrapper objects can be more expensive to create - but they prevent external code from simply being able to perform a type-cast to get around immutability. This is, by the way, the mechanism that ReadOnlyCollection<T> uses to return immutable collections.
To overcome that fact that collection types have limited casting support, you can use LINQ to return a immutable copy of the immutable type:
_containersUnderMinimum.Cast<IInvalidContainer>().ToList().AsReadOnly()
This creates a copy of the collection - but it may be good enough - if you don't need to the collection to reflect changes at runtime.
Also, be aware that ReadOnlyCollection does not require (or enforce) immutability of the elements of the collection. Rather, it prevents the receiver from being able to add or remove elements - changing existing elements in the collection is still possible.
Actually, it is possible to cast generic collections:
ReadOnlyCollection<IInvalidContainer> result =
_containersUnderMinimum.Cast<IInvalidContainer>().ToList().AsReadOnly();
However, this does not stop the consumer from casting the elements back.
If your mutable objects can only be changed via methods, I would suggest that you include within your mutable type a reference which, if non-null, will identify an instance of an immutable type which encapsulates that same data. Your mutable type should include a method to create an immutable copy; that method should make and cache a new immutable object if it doesn't already hold a reference to one. Otherwise it should return the cached reference. Any mutating method should invalidate the immutable-object reference. Using that approach, one should be able to avoid having to make repeated copies of objects that are never mutated.
Maybe I'm misunderstanding, but a ReadOnlyCollection only implies that the collection is ReadOnly, not the objects themselves...
Please I have a class in c# whose main function is to return the types and objects as dictionary Over a service .
Is it possible to cast the Object sents over the WCF service in the front end.
I.e using reflection to get the type of an object from the types.ToString() and using the type to cast the objects.
NB the Class that returns the dictionary and my frontend are in different projects so different Namespaces:
Type repType = typeof(List <>).MakeGenericType(Type.GetType(EntityandTypes[entity]));
object rep = Assembly.GetAssembly(repType).CreateInstance(repType.FullName);
grdResult.ItemsSource =
e.Result.ToList().Cast<typeof(Type.GetType(EntityandTypes[entity]))>();
Note : EntityandTypes is a dictionary that contains Object and Their types.
What would you want to do with the cast values? Casts usually make a difference at compile-time whereas you're asking for something at execution-time.
If you can explain how you'd want to use this, we can probably help you design around it.
What sort of types are we talking about? classes? And what type of service is it?
If it is WCF, one option is to use type-sharing to use the same type at each end, but this abuses SOA a little bit. You can't cast a class to a very different type, but you can project into a different class. Various approaches for this are discussed here:
How to copy value from class X to class Y with the same property name in c#?