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
|
Hi, currently there is an error with doing associations. If you add a OneToManyAssociation (or probably any type of association I'm guessing), it will infer a foreign key and it always infers it as an Int32. However, quite a few of my foreign keys are different types, such as: Byte, UInt16, UInt32, etc. etc. I would love to be able to add relations to the Lightspeed class, but it is not possible until the foreign key types are changed. Thanks |
|
|
I just realized, it is also not generating the primary key's type correctly ... it is always Int32. A lot of the primary keys in our database are of type Byte (since they are small lookup tables). |
|
|
We don't really support identities of type other than Int32, Int64, Guid and String at the moment. They can be made to work but (a) you wouldn't be able to insert new records (which is probably not an issue for your lookup tables) and (b) you would need to write the entity declarations in C# or Visual Basic rather than using the designer. (Technically, there is a way you could get away with only writing the relationships in C# or Visual Basic, but if you were to do that, there's probably not much point putting the rest of it in the designer.) We are looking into making some changes which would address the second issue and we will get back to you about this. |
|
|
Any update on this? Would still love to have this feature... |
|
|
We're not in a position to look at this right now because we're doing some significant work on the designer to add stored procedure support. We'll try to get onto it once the sproc support is stable enough to include in shipping nightlies. This probably means we'll look at it early next week. Keep chasing us! |
|
|
Hello SpinMaster, We've ended up taking a slightly different route out of this. LightSpeed actually copes with tinyint, smallint and unsigned keys without any problem. You specify the identity type as Int32 in the designer (or inherit from Entity<int>), and LightSpeed takes care of converting to and from the native database type as required. However, in the past this has caused a problem for associations to such entities. Our code for loading data fields is optimised for performance, and has required the CLR field type to exactly match the database type. (Whereas the code for loading ID fields is more forgiving.) For example, if the ParentId column in the database is smallint, then the ParentId field in LightSpeed had to be short (Int16). If you were writing entities by hand, this wasn't a problem, because
a Int16 ParentId could happily refer to an Entity<Int32> Parent
class; but the designer, as you noted, didn't offer this option. The designer's code generator always generated ParentId with the same type as the identity type of Parent, typically Int32. We looked at a number of solutions for this, which basically came down to two options: allow you to explicitly specify the type of ParentId when using the designer (as a property of the association), or change our data load code to be more forgiving around integer type conversions. Of these two, we believe that the second is preferable because it reduces the need for micro-management, both in the entity definitions (an int/uint mismatch will no longer cause a cast exception) and in the designer (specifying the XxxId field type would have been one more thing to worry about and potentially to get wrong). The only question was whether we could do this without affecting performance, and based on our testing we believe we have managed this. So this is the route we have taken. So, after all that, what does this mean for your question/issue about associations? 1. We are *not* giving you the option to specify the type of the foreign key (the XxxId field). It will always be the type of the associated entity. 2. We will continue to infer Int32 or Int64 as the entity type, even if the database Id column is unsigned or small/tinyint. 3. But now associations will "just work" -- you will not need the feature described in #1. Apologies for the lengthy explanation, but I thought it would be useful for you to know why we appear to have done something other than what you asked for. We believe it solves the actual problem that you've encountered, and is a better approach than what we originally considered. The fix will be available in nightly builds dated 6 November 2008 and above. Please let us know if you run into any problems with it. |
|
|
Hi Ivan, I prefer your solution better, it makes it simpler to use :) However, I am still getting a "Specified cast is not valid" as the InnerException for the following exception: "Unable to materialize field [KeyCodeProjectId] on type [SpinMaster.LightSpeed.KeyCode]. See inner exception for details"
In the database, keycode_project_id is an unsigned INT. I'm also getting errors for another field that is an unsigned TINYINT.
I am using the Enterprise version labeled "LightSpeedEnterprise-20081106.msi"
BTW this is SpinMasterStudios, I'm just using the email of my coworker who was the one who purchased the software |
|
|
Could you zip up the relevant CREATE TABLE script(s) and your LightSpeed model (.cs or .vb file) and post them (use the options tab to attach a file) or email them via the contact form (if the content is sensitive) and I will look into this. (You are using MySQL, right?) Thanks! |
|
|
I'm sorry, I realized that even though I installed the latest version, my project was still referencing the old DLLs - once I copied over the new DLLs everything worked fine :) Great job on this change, now I can add relationships even though the database is MyISAM and everything works perfectly. Thanks again |
|