SimpleDB One intstance multiple domains

Hi All,

I'm using LightSpeed for a project that uses Amazon SimpleDB. So far so good, but I just bumped into something I couldn't figure out after a couple of hours going through the forum.

In this scenario I have a campaigns and campaignItems domains/tables. Campaign items can be very hefty at times, going up to a couple million rows per campaign, so I decided to follow Amazon's best practice call and went after a canonical Domain naming scheme, such as all the campaignitems for campaign ID 99 are in a domain called CampaignItems_99

What would be the right way to map my CampaignItem entity to the correct domain, dynamically at runtime?

Thanks in advance,

Kind regards

Chad

We don't support this kind of scheme at the moment.  You might be able to kludge something together using an INamingStrategy that figured out the right suffix on the fly, but you'd need some way to explicitly communicate the correct suffix to the naming strategy just before the query happened (and you'd need to take care that simultaneous queries running on different threads didn't tread on each others' toes).  I'll see if we can think of a better solution but I'm afraid this is the only option for now.

Hi Ivan,

Thank you for the clarification. I will look into INamingStrategy to see if I can leverage what's in there to that effect. In the meantime, a feature like having the ability to partition data in different domains would add an extra bit of awesomeness to an already awesome product!

Regards

Chad

What would be a good place to hook, to do something just before the query happened?

It depends on the structure of your program.  It sounds like you will mainly be accessing items via associations, in which case you can manually implement the association and hook the collection getter:

partial class Campaign {
  public EntityCollection<CampaignItem> CampaignItems {
    get {
      // Hook naming strategy
      return Get(_campaignItems);
    }
  }
}

If you are looking up items directly, then you will probably need to encapsulate the lookup in a repository method e.g.

public List<CampaignItem> GetCampaignItems(int campaignId, SomeOtherCriteria criteria) {
  // Hook naming strategy
  // Perform query
}

The other side of the coin is saving.  You should be able to handle this by overriding CampaignItem.OnSaving and hooking the naming strategy there, but I'd advise careful testing.  If that doesn't work, you may find you need to restrict yourself to saving only campaign items from one campaign in each SaveChanges() call.

To be clear, we've not ever had to do this ourselves, so you're venturing onto new ground here.  I'd strongly advise prototyping to get a quick sense of whether this solution is going to work for you, before committing too much time to a production-quality implementation.

Thanks so much Ivan!

I have a knack for getting my self tangled into edge cases like this all the time :)

I'm more inclined to try out the entitycollection's getter method to hook-up the naming strategy. Passing on the right campaignID might present some challenge, but that's easily avoidable by confining each UOW to single campaign i presume.

I'll let you know.

C

If you can confine each UOW to a single campaign then you are gold (ish) -- you can just use a new LightSpeedContext for each unit of work, then set up a suitable naming strategy when you create that LightSpeedContext:

internal static T GetUnitOfWork<T>(int campaignId) where T : IUnitOfWork {
  LightSpeedContext<T> context = new LightSpeedContext<T> {
    NamingStrategy = new PerCampaignNamingStrategy(campaignId),
    DataProvider = // etc.
  };
  return context.CreateUnitOfWork();
}

I know this runs against our normal guideline of 'LightSpeedContext should be a singleton' but it's in a good cause -- much cleaner than trying to switch suffixes on the fly!

Ivan, you're the man.

Works like a charm at the cost of UOW not being a singleton, but in this particular implementation, UOWs are encapsulated in a class that runs in its own thread, so i couldn't care less.

Thank you very much for pointing at the right direction

Kind Regards

C