Hello,
I've considered using the db4o OODBMS with a recent Silverlight / RIA Services project, but there's one point that I could use some advice on - how to make associations work. RIA Services requires that you mark all of your associated entities with an AssociationAttribute. The AssociationAttribute's constructer requires that you specify your entity's key to the associated entity, and the key of the associated entity itself.
As an example, imagine that I have a Racer class with CarID and Car properties, and a Car class with an ID property. My Racer class would look something like this:
class Racer
{
public int ID { get; set; }
public int? CarID { get; set; }
[Association("Racer_Car", "CarID", "ID")]
public Car Car { get; set; }
}
The problem that I see with using db4o (or any OODBMS) is that foreign keys and primary keys do not, and need not, exist - and the result is that I wouldn't need the Racer.CarID and Car.ID properties. To make this work with RIA Services, I would need to create my own unique keys, which I don't mind, I just don't know the best way to go about doing so.
So my question for you is "how would you create these keys/IDs"?
Since there isn't any concept of an auto incrementing generated field (none that I'm aware of any way), I would have to choose between trying to manually, safely increment the keys, or use something like a Guid. Since the former would be more difficult to manage with multiple users and/or multithreading, I'd imagine that using a Guid would be the simplest solution.
So let's consider using a Guid. The easiest solution would be to create my ID properties, just as I had within the example above, but use a Guid instead of int. I would need to set the ID to a new Guid after creating new entities - then, whenever I set the the Racer.Car property, I would also need to set the Racer.CarID.
Doing that by hand would be prone to error, so I'd want a lot of that handled in the property getters and setters, but I'm not sure of the best way to implement that.
That's what I've thought of so far. I think I'll look into how the Linq-to-SQL generated code handles some of these concerns - maybe I'll find a clue there.
Any suggestions would be greatly appreciated.
Thanks,
-Charles