We're evaluating Lightspeed and have some questions

Greetings,

We have a few developers evaluating Lightspeed and we have some questions and concerns:

1) Does Lightspeed support composite primary keys? If not how would we use Lightspeed when composite keys are desired?

2) We have not had success creating Entities based on views. Is this supported?

3) We are an Oracle shop. We're concerned with the way Lightspeed seems to handle auto-numbered columns. It looks like there is one sequence shared by all id keys. This idea doesn't thrill us. Is there a way to have one sequence per id key? Also we are seeing occasional repeating values, mostly when creating and adding new entries in a for / foreach loop.

4) In some cases when Lightspeed saves changes to the database (by this I mean the database structure) we are seeing "NOT NULL" when NULL's are specifically allowed.

5) Our architecture is a modular/expandable app. There are services provided by different modules that may or may not be installed in the system. So we may have several assemblies performing database tasks that we want to be in a single transaction. Additionally, our Lightspeed models will be spread out over several potential assemblies. The question is: In this scenario how can we use the Lightspeed's Unit Of Work construct to manage transactions?

Thanks

-Bert

Hello Bert,

1. LightSpeed does not support composite primary keys.  If you are designing a database from scratch then we would suggest using surrogate keys.  If you have an existing database which contains composite keys then there are some suggestions at http://www.mindscape.co.nz/forums/Thread.aspx?ThreadID=1735.

2. Yes, it is.  Is your problem in dragging views onto the designer, or in instantiating the entities?  If the former, what problem do you see, e.g. wrong columns, no entity created, etc.?  (You are using Oracle, right?)  If the latter, is the view name the same as the entity name?  What exception or other incorrect behaviour are you getting?

3. We don't currently support per-table sequences.  One way to implement this -- and please pardon any errors, it's a long time since I did any Oracle design -- would be to put an insert trigger on each table to populate the ID column from your per-table sequence.  You could then use the LightSpeed IdentityColumn identity method, which retrieves the ID from the database after the insert happens.

Could you say a bit more what you're doing that causes the repeating values issue?  We've not seen this issue before and we'd like to investigate further.

4. You are talking about the designer "Update Database" feature here, is that correct?  If so could you send us the .lsmodel file (you can attach files via the Options tab, or email it via the contact form if it contains sensitive info) and we will investigate.  Thanks!

5. If you are using IUnitOfWork and the core API (IUnitOfWork.Find<T> etc.) then this should not be an issue.  Just create a unit of work and begin a transaction on it.  If you want to use a strong-typed unit of work classes created by the designer for LINQ support (MyUnitOfWork.Orders etc.), then you have two options:

(1) Create your own strong-typed unit of work class patterned on the generated code in the designer, and declare properties for *all* the types in all the different models.  This will probably not work for you because you don't want a centralised class with dependencies on all the "bits" of the model.

(2) Use the weak-typed IUnitOfWork, and call Query<T> explicitly, e.g. write uow.Query<Order>()  rather than uow.Orders.  This means that you take dependencies on particular bits of the model only when you need them.

In either of these two cases the idea is to have a single unit of work instance which can handle all the bits required in a particular transaction.  Then you just call uow.BeginTransaction(), or create a TransactionScope, and you're away.   You can make option 2 a bit prettier by using a Repository pattern and a unit of work scope (see UnitOfWorkScopeBase and PerRequestUnitOfWork).

Hope this clarifies things -- please feel free to follow up if you need any further info, and if you can get us repro cases for those issues you mentioned then we'd really appreciate it!  Thanks!

Just to follow up on the repeating values issue you mention in (3), it looks like this may happen if the LightSpeedContext.IdentityBlockSize is greater than the LightSpeed sequence INCREMENT BY, *and* you add more than the IdentityBlockSize number of entities.  If this is true in your case, a workaround is to increase the INCREMENT BY to be equal to or greater than the IdentityBlockSize (which defaults to 10).

I appreciate that you're "not thrilled" with the single sequence of IDs and I'm guessing your concern may be that they get chewed up too quickly, which a large INCREMENT BY will obviously affect.  If you could say more about your concerns then we'd be happy to work with you to address them.