mORMot Open Source

TPrami

Member

Registered: 2010-07-06

Posts: 119

Question and feature requests (etc)

Hello,

I've been evaluating the framework for little bit and some my impression so far.  (Quite a lot of text, I know )

Somethings is possibly I do not know enough, I've been looking the demos and browsing the documentation, but I might have missed the information... And there are my opinions and I just like to bring them to table, to prove me right or wrong does not matter, just to make framework better and more information available...

1. To be sure that everything works and if some logic is broken (Delphi side) Db should have Foreign keys. I know I could just add and manage them at the DB-level, but I would love to handle DB-agnostic way at the Framework level. If I accidentally mess up at Delphi code the DB would prevent then the garbage data to appearing into the DB. whic might be very very difficult task to correct. So I would like to set up it at the same time while I make the Model for the DB into the Framework.

2. Mode should also have more information, I think it should have the relationships of the Tables/Objects (The foreign key information). Which fields map to each other. This could then manage on the Db-level if permitted to do so. Also maybe the natural Primary key or the Data, (or I am missing something here). Because now there is always ID as primary key, but it might not be very logical way to mode the data into the Db. If Framework depends on it, but I would like to have some index/unique index feature into the mode, where I could lay ot the mode which record actually is unique. Also this infor could be used to enable easier high level queries (Like I talk in the part 4.)

3. For now biggest thing is that the  TSQLRecord as property of TSQLRecord.

like

TDistrict = class(TSQLRecord)
end;

TAddress = class(TSQLRecord)
  ..
  property District: TDistrict ..
end;

TPerson = class(TSQLRecord)
  property Address: TSQLRecord
end;

I know I could to that, but the fact that the properties are not actual object instances is worrying, easy to mess it up because framework forces to code nonstandard way.

I really can't understand why this is this way. I would think that there is way to do this even in the older Delphi versions somehow. Maybe it would need some coding/TSQLRecord. I would live with some

TPerson = class(TSQLRecord)
protected
  procedure CreateObjectProperties; override;
published
  property Address: TSQLRecord
end;

Only there should be some way to get it initialized. But the fact that I have object property that is not NIL and it is actually not an Object I do not like that. (Changing it will change the existing code quite much, but it would be change to the better IMHO).

Maybe better yet would be to use some kind of Dependency injection and/or factory for this... So would have to just register it once and it would be taken care of...

There might be some underlying thing I do not understand or I am missing completely, but this kind of change alone would do very good indeed.

3. I am not sure but I think at the framework level should be helpers for the complex Db structures. More than less Tree like structures and so on. Because setting those up and having all the Queries for them Object and Db structure. I think is is where Db-apps get very complicated easily.

Think of an Tree structure and each node would have multiple items liked into it at other table(s). Then you might have logic that should all from selection up, from selection down, at same level etc. I am not the Db-guy, but what experience I have, is the SQL get's very complicated very fast. And I am hoping to get far as I can from the SQL after it is even slighly more complicated that select * from Person where ID=1.

4. I think that the Framework is still too close on the SQL at the where clauses. It is the SQL in my opinion.

Fluent interfaces are one solution but I think it can be as Complicated as any, but would get make 100% db agnostics, because if I recall like string and date etc handling can be different at different DB back ends if there is no some abstraction framework level.

I would like more some kind of other solution this where caluse also. Maybe I could register the queries with some tool for each TSQLRecoed (etc) and the tool would write the code for me. Like (Not very much thought on this but something like this)

TPersonList.Create(const AEmailAddress: string);

To make API much of Delphi code and none of SQL if possible... I know I could hand code this right now. But so does have to eveyone. just the idea of getting more ready to run stuff out of the system. Writing lot of trivial code and maintaining it also is some what error prone... Many bugs are at trivial pieces of the code which you do not concentrate so hard, because you know it is so simple

5. Some kind of GUI helper would be very very important. Like the Live Bindings now in the new Delphi version. It could have Regular expression validation and/or just Delphi code shared (The Model) level. Which possibly could at least at regular expression flavor could be updated separate of the Client Change.  (No need for client Update). hcOPF has quite interesting stuff for making GUI programming easy and in same time separating the GUI and your own code. Quite simple program easily have tons of the code for GUI handling only. (Need lot of work I know, I have some demo which I could donate for inspiration for Validation code). And for Most part would be cool to have possibility to easily set up the Object property to the Component. And data would get displayed as defined easily. And mainly easily updated also. As I think some old projects I've been looking at, there are so much code for the GUI also. And I think the Delphi standard Db-Aware way is not good, not even close. But ORM-style way would need powerful tools to get the data displayed and edited and so...

Think of some kind of tree structure in DB and showing it and show the list of data in grid to depending on the Tree selection, then maybe editing the Tree Structure and edit and/or move data around and so (Which ever is permitted in the app) this alone would be very big. And if we all make it from the scratch it is very much work. I am not saying Ab should solve my all problems. (We users might also pitch in ). But for this kind of Framework I think anyone who is willing to help  do have to have some directions and guidelines to go by, so everything would stay consistent and would use underlying code in optimal way.

....

I think this framework is little bit kind of "Engineer-code". If you know how it works and been using it it is very good. I think just bringing the level of expertise needed more down (low level might be there or not doesn't matter would be better. To have tools to make things much easier. As for now it solves maybe the biggest part of the puzzle. and some things that is troublesome to write and make effective (Caching of any kind effective and tight data transport for client server communication and so...)

Also I would like to see the framework refactored in few smaller chunks to have more easy access on some part if also part of it is needed for some project. Like BigTable is... Would think the JSON parser and forming and Serialization from objects back and forth. And maybe some other parts of also (Made similar suggestion at somewhere on the forums some time back I think)

-Tee-

Last edited by TPrami (2012-11-15 13:23:36)

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,659

Website

Re: Question and feature requests (etc)

Thanks a lot for your input.
Very valuable material here!

I've added three new entries to the official project roadmap at ORM level:
- Implements structures like Trees;
- Implements foreign keys;
- Introduce TSQLRecord published properties instance auto-creation.
See http://synopse.info/fossil/wiki?name=RoadMap

Note that foreign keys are not handled at DB level, but at ORM level: when you delete an item, all associated items are also deleted - this is the CASCADE way. RESTRICT is missing.
This is only one way of doing it, so we may have to handle it at the DB level, if possible.
Potential issue is that it should work also with no SQL DB back-end, e.g. for pure in-memory tables.

I understand your concern about TSQLRecord.
Implementing lazy loading and such is the problem.
You should consider creating your own instance field in such case, with a getter/setter at the ID.
A possible enhancement could be to optionally create the TSQLRecord instances, and handle the ID from the instances, and make a JOINEd query, just like many-to-many relationship.
But it could be implemented in the future, since there is something similar already working for TSQLRecordMany.

Any feedback, suggestion and implementation pattern is welcome!

esmondb

Member

From: London

Registered: 2010-07-20

Posts: 299

Re: Question and feature requests (etc)

I like the idea of helpers for complex Db structures or wrapping them in an object.

Trees would be really helpful with the 'nested sets' implementation looking most useful for me:

http://stackoverflow.com/questions/3173 … structures

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,659

Website

Re: Question and feature requests (etc)

@Esmond

Thanks for the link!
Nice ideas...

TPrami

Member

Registered: 2010-07-06

Posts: 119

Re: Question and feature requests (etc)

Hello again...

just remembered I had stored couple links for the later...

http://www.slideshare.net/quipo/trees-i … esentation

Hope this helps...

TPrami

Member

Registered: 2010-07-06

Posts: 119

Re: Question and feature requests (etc)

Thanks a lot for your input.
Very valuable material here!

Thanks...

Note that foreign keys are not handled at DB level, but at ORM level: when you delete an item, all associated items are also deleted - this is the CASCADE way. RESTRICT is missing. This is only one way of doing it, so we may have to handle it at the DB level, if possible.
Potential issue is that it should work also with no SQL DB back-end, e.g. for pure in-memory tables.

Yes...

Way to create foreign key hierarchy between those  for those tables exist in the DB and maintaiunin/creating them from Delphi side (needed/possible) would be quite good life insurance.

It is very difficult to start fixing the DB after you've put something garbage in it... If your (user) code contains bug and you modify DB with wrong ID's you are big trouble...

I understand your concern about TSQLRecord.
Implementing lazy loading and such is the problem.
You should consider creating your own instance field in such case, with a getter/setter at the ID.
A possible enhancement could be to optionally create the TSQLRecord instances, and handle the ID from the instances, and make a JOINEd query, just like many-to-many relationship.
But it could be implemented in the future, since there is something similar already working for TSQLRecordMany.

Yes...

This might be the Right way to go for now...

Building factory, that supports all lazy load and so, would be quite difficult, maybe...

But Still i think that would be the way to go, way or other...
´....

btw... for us newbies would be good to have simplest possible demos to tinker around, to show what is to correct way to do certain feature.

Like one to many etc relation ships... Looking from documentation might take too much time and usually contains information which is not relevant on the Simplest possible solution (Or other way around maybe, documentation would bee too vast if all examples and code snippets would contain ready to run code...)

I wold also stress the importance of having GUI support maybe we users could start project on that, it would use Synopse code where it would be smart, (Like serialization code must contain code needed to get properties and fill them back again).

I would think that it should have few key features (Not too carefully thought out, so it might not be the optimal plan).

1. Fast
2. Easy interface (self explaining)
3. High level (Fallback) code formatters and parsers
3.1 Possibility to override the formatters and parser for different needs (Like Double might be money or so)
3.2 Possible to setup  parser for single property or some larger group
4. Possibility to register Mediators (The UI component handlers, I think they are called mediators )
4.2 Maybe single source file for mediator and maybe some standard collections for components that are in Single standard Delphi unit.
5. Some neat way to inform user (configurable and way to disable) that the value is not valid
5.1 There should be Regular expression validators and way to use something else also (Delphi code)
5.2 Possibility to update at least the regEx validators from the server side
5.3 Auto correct feature would be sweet. Some trivial would be that entering 0.10€ would be converted to 0,10€ automatically on my locale. It is very annoying if the UI will not help such trivial stuff, but again this should not be forced, and maybe again some neat way to inform user...
5.4 I've made some demo lib for some kind of value validation which used regular expressions, and it used some predefined background colors when possible, and some code I've found somewhere to pain subtle frame around the component depending is the value correct or not. It was few years back so I do not remember all details...

So what do you think? Would we able to start collaboration project on this??

-Tee-

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,659

Website

Re: Question and feature requests (etc)

Any help and contributions are welcome.

See http://synopse.info/forum/viewtopic.php?pid=6555#p6555 about a corresponding discussion.