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 These are a couple of thoughts after playing with LightSpeed: 1. How does the KeyTable identity method work and what are its pros/cons verses sequences/guids? The hinted at description is missing from the quickstart guide. 2. Why default to KeyTable? I would have thought sequences were the most popular choice (at least in SQL Server land. Did you choose KeyTable because not all databases support sequences?). 3. Personally I prefer prefixing the primary key with the table name, i.e. PersonId rather than Id. It would be useful to have an attribute that you could apply to an entity which specifies what the primary key is called. 4. I was testing in a console application and I noticed all the SQL Lightspeed generates is being written to the console.
I also have a question. Say I have added many entities to Repository but one of them breaks a constraint on the table. What will happen when Save on the Repositoy is called? Will the entities that were added before the broken one be saved or will they all get rolled back?
~ James |
|
|
Hi James, Thanks for the feedback. Answers inline: [quote user="James Newton-King"]1. How does the KeyTable identity method work and what are its pros/cons verses sequences/guids? The hinted at description is missing from the quickstart guide.[/quote] The key table is an efficient, portable identity generation mechanism for generating database-wide unique integers. It's primary advantage over Guids is that integers can be nicer for things like friendly URIs. If this wasn't a concern, I would favour Guids. Unfortunately, Sql Server doesn't support first-class Sequences like Oracle or Postgres have, but if I were using either of these back-ends I would use our Sequence strategy as it is a cleaner, faster version of KeyTable. For more on Key Table see Fowler's PoEAA book. [quote user="James Newton-King"]2. Why default to KeyTable? I would have thought sequences were the most popular choice (at least in SQL Server land. Did you choose KeyTable because not all databases support sequences?).[/quote] Do you mean auto increment identity columns? This something we've debated internally. I'm not that keen of them to be honest because of their poor performance and lack of database-wide uniqueness. If people feel strongly about this we will implement it. [quote user="James Newton-King"]3. Personally I prefer prefixing the primary key with the table name, i.e. PersonId rather than Id. It would be useful to have an attribute that you could apply to an entity which specifies what the primary key is called.[/quote] Noted. Yep, improving the logging will happen soon. [quote user="James Newton-King"]I also have a question. Say I have added many entities to Repository but one of them breaks a constraint on the table. What will happen when Save on the Repositoy is called? Will the entities that were added before the broken one be saved or will they all get rolled back?[/quote] Currently, this is up to you. If you want a transaction then use TransactionScope. I think the flush needs to be in a transaction however, so I'm planning to improve this for the next release. Cheers, Andrew. |
|
|
[quote user="AndrewP"]Do you mean auto increment identity columns? This something we've debated internally. I'm not that keen of them to be honest because of their poor performance and lack of database-wide uniqueness. If people feel strongly about this we will implement it.[/quote] Opps yes I ment Identity. [quote user="AndrewP"]Currently, this is up to you. If you want a transaction then use TransactionScope. I think the flush needs to be in a transaction however, so I'm planning to improve this for the next release.[/quote] Ok I just wanted to check whether it was nessessary to wrap a single call to save in a TransactionScope. Perhaps it might be an idea to provide an overload to SaveChanges that adds the transaction for you? ~ James |
|
|
Is it a requirement that object keys are unique across the database?
I guess I am asking because when I need to justify a decision to use Lightspeed for a real customer over another solution, then I will need to be able to convince the powers that be that deviating from current good practice conventions is justifiable.
Dolan |
|
|
Hi Dolan, The performance issue is that we have to insert, then query back a new record in order to know it's id. Whereas, our current strategies don't require this. There are also some secondary gains from being able to assume that keys are database unique. Let me know if it's a show stopper. Cheers, Andrew. |
|