- I create a MetaClass
- When I change the name of a MetaClass from the default, it creates a same named table in the database. If I change it later, it asks if we want to delete the old one and create the new.
- When I add a MetaProperty to the MetaClass, a field with the same name is added to the database.
- I'd like to see a column added to the MetaProperty space that is a checkbox for Nullable. When that is clicked, it should mirror the setting on the database side.
- MetaProperty type names should support condensed type format like SQL Server does. So, you can type 'String' which translates to either 'varchar(max)' or 'nvarchar(max)' (another setting for the model). But if you type 'String(55)' then it becomes 'varchar(55)' or 'nvarchar(55)' in the database.
- I would also like to see an option for the ORM itself enforce these length limits, which is huge for security in terms of buffer overruns and such. Maybe raise a special type of exception or simply truncate the string? Again, probably a model setting.
- Finally, if I'm editing a model, and the property name matches the database property name, I would like you to connect them automatically for me at the time of change only. Then, if I disagree with the default, I can go to the table mappings tab to override it.
The above would save a ton of time in the model designer for me.
5 Answers, 1 is accepted
First of all let me try and clarify a bit. Telerik OpenAccess ORM uses two models, a conceptual one and a relational one. The conceptual consist of all the classes and their definitions and the relational is an (almost) exact copy of the database schema.
That would mean that in a forward mapping scenario we would first create both models and then call the schema handler to persist the changes to the database. There is a workaround however, if there is no relational model defined one would be assumed with default values and you could map a conceptual type directly to the database without a relational layer.
The schema update operation however has some limitations. It cannot know for a fact that a change has been made to model, rather it can only guess. So when you rename a table it sees it as removed, and see a new table with the new name. This is something that we might not improve in the near future as it would require quite a lot of work.
As to the nullability suggestion it is a rather good one, however we were thinking of something like a context menu that you can specify (as first and second option) if it is a primary key and if it is nullable.
We are currently working on a new implementation of the types system that would allow customization and extension points for developers that would make this a breeze.
As to your last point I am not really sure what you mean, if you do have your table in the relational model (schema explorer) you could simply right click and say map to class. Then modify the class the way you want. However we are taking into account your suggestion and we will consider implementing it for the next version.
Please point out to me if I have missed something or something is unclear. I hope this is helpful.
Serge
the Telerik team
Rank 1
I also understand the separation between the model and the SQL schema. I tend to make them match fairly closely, but don't want to force that. What I'm saying is that when you create a new entity, I suspect most would want it mirrored as a default. Same for adding one more property. After that, you could stay out of it.
When I was talking about property modifiers, I was thinking how Microsoft SQL Server Management Studio does it in the SQL diagram view, when you select custom then add identity, nullable, condensed type, and default value. I have found no better way to do it, and would be ecstatic if you guys adopted a similar interface.
Also, it would be huge, once again, to have the condensed type support data type length, which the model could enforce in code, and in the SQL schema where it is the maximum length of the type. For example, string(55) means nvarchar(55), so if someone enters more than 55 chars, they either get pruned or raise an exception -- let the developer choose.
Hope that helps. Just trying to save a ton of time setting up models and schemas.
This behavior comes from the fact the that we tend to develop a database agnostic model or at least for the biggest part of it. This is targeting the forward mapping scenarios so that the customers are able to easily deploy on any kind of database server that OpenAccess supports. That is why we, during runtime, calculate all of the relational based artifacts from the Database Server we are connecting to, unless they have been specified before explicitly by the user.
We have planned improvement and more clarification on this matter however they are not yet introduced or developed.
As always your suggestion are very helpful and I have taken notes and I will bring them up in the next planning meeting.
Thank you and have a nice day.
Serge
the Telerik team
Rank 1
I agree that the goal of the Model is to create a database agnostic schema. GREAT, that is why we use an ORM. However, what you seem to be missing that the normalized ontology for that model could be better, and made much easier for us to use without a ton of effort.
For example, suppose I want to add a 'Name' attribute to my entity table 'Person'. Here is what I want to be able to do and to have happen:
- Add 'Name' to table 'Person' in .rlinq file
- Specify 'Name' as a 'String(50)', which means it is limited to 50 characters by the ORM with a hard trim (causing a user-selectable exception or simply cut it short).
- Have an icon on the top of the 'Person' table to create/update the underlying SQL database table.
- If 'Person' does not exist already as an SQL database table, it is created, then a 'Name' property of type 'varchar(50)' is added. This means the database itself won't accept more than 50 characters, and can use that to save space on the hard disk.
- Person.Name Model is mapped to Person.Name SQL Table for me
PLEASE include the above one of your next releases (after programmatic generation of schema). Thanks!
Thank you for your valuable suggestions. In fact, we are working towards making the designer friendlier and the first significant improvement in that direction will be the associations handling. We definitely want to make the experience with the mapping of the classes better but we want to make sure that the update of the relational layer is a firm decision made by the user. We would not like to mix relational concepts with conceptual ones and that is why we would try to provide a unified view of both models. The user will be able to control more easily the mapping process by being able to see both models at the same time.
We will take your suggestions into consideration and although the features you described may not appear in the same form we will try to make an improvement in the directions you have specified. Feel free to bring to our attention anything else that you find is worth mentioning.
Kind regards,
Petko_I
the Telerik team