In my base class of my entities (this base class has is not mapped as entity) I have some properties that are not tagged also.
I have to keep them as read only properties since if I make them read and write (get and set) when using TAureliusDataset it give me an error saying that this property is required to be entered.
And that is not correct.
It is nice that TAD expose them, but if it is not expected that those properties are marked as required. Going to the FieldDefs and change it is not an option, since I frequently reload the definitions.
Any property that is not Nullable is marked as requred by the TAureliusDataset automatically, if it's not [Column] mapped. A (very ugly) workaround would be just add a [Column] attribute to those properties without the TColumnProp.Required option, so it will understand it's not required.
OK, but in this case the property will turn to be table column and persisted... I dont want that either... I am having to have read only properties and use separated set procedures when I need to write making the class looking ugly.
When the property returns an Interface I can have a read and write property, but not for much use.
this is the base class of all my entities. For those entities that does not use inheritance strategy it will be mapped as a table row, that is not desirable.
I think this is an important issue since I dont want that my entities classes be only a table representation. Polimorphism is important in many situations for me. I see that you commonly deal with the entities at TObject level and retrieve info by RTTI, but I am not a RTTI fan guy, so I prefer to have a base class and get from it what is common most of the time. Aurelius should not break these things.
I am fine if needed to add tags to tell aurelius to NOT MAP to a table. and in some cases NOT SHOW in the TAD.
Just and idea, out of this, you could enrich the FieldsDef window with a better looking view with color or icons. Giving more information of what is Table Fields, what is Class properties, read only, required etc. Visually makes easier to work. What I see in business apps is that after you solve the framework part you enter in the process of adding fields and connecting tables and that uses the other side of the brain :) visual things help on this case.
back to the problem, I will stick to the get and set for while, until I see a solution coming from the oven. Thanks
Not sure what do you mean by "not rtti"? Aurelius grabs information about the objects/properties at runtime, I don't see any remote possible option that it works without RTTI. How would Aurelius know that your TCustomer class has a Birthday property that needs to be saved, for example????? And read/set the value for that property?????
I just mentioned a workaround for you to going on, I even mentioned it's an ugly one. Ideally it could be an checkbox option in dataset fields importer that doesn't consider non-nullable properties as required (if they are not mapped).
The Dataset fields editor is the default Delphi built-in, I don't think we can change anything on it unless we completely remove it and create our own writing it from scratch. The features you mentioned could be implemented in the fields editor itself indeed, like read-only, required indications, etc., are things that fields editor itself could do (regardless if it's from aurelius dataset or any other regular dataset).