You are not logged in.
Pages: 1
Supposing I have an object that has a text field with a JSON object containing properties. Defining that for ORM is pretty simple. I like how simple it is, in fact.
But what if I want to override how it's actually saved in the database on the server? For example, if I want to compress the text, then encrypt it. And, since I still want the database to use a text field, encode it with base64.
Is it possible to override the load/save on the server to accomplish that?
The idea is that the client never knows. The client just says "Gimme" and the object appears with the field in its normal (decoded, decrypted, and decompressed) JSON state. NOTE: This idea assumes secure communication between the client and the server, providing "security in flight".
Since Sqlite doesn't really *care* what you stuff into a TEXT field, I suppose it might be possible to skip the base64 encoding and just load/save as binary.
So, ignoring that this might be considered "odd", is it possible?
Thanks!
-David
Offline
Don't rely on SQLite3 particularities, unless you directly access it.
From the ORM/REST point of view, you may just use a BLOB in all cases, even if the BLOB contains plain UTF-8 encoded text.
You can put your logic in the TSQLRecord, using a BLOB published property for the storage, but public pseudo-properties with getter and setter methods, to access the JSON state.
Also note that our ORM supports natively JSON, if you define a variant published property and store a TDocVariant within.
You could then search within the stored JSON, and also it will be stored as a sub-object or a sub-array when stored in MongoDB.
Offline
Peculiarities of Sqlite aside: Is it possible to override the how a field is loaded/saved on the server?
I can see a case for creating a separation in the data layer, and the new layer provides the encryption/decryption.
-David
Offline
Looking through the Sqlite3\DDD files, I can see one way it could (maybe) happen: hooking into the repository interface implementation.
Maybe creating an intermediary class? A DTO, maybe?
For example, using the TUser class from the Sqlite3\DDD\dom folder, instead of having a TSQLRecordUser class that's a field-for-field match of TUser, have a TUserDTO and a TSQLRecordUserDTO. TInfraRepoUser methods are passed a TUser object. The methods convert the TUser to a TUserDTO (consolidating fields, compressing, whatever), then call the ORM* commands.
What would that break? Offhand, I can see it might screw with the automatic table naming.
How far into left field have I wandered?
-David
Offline
Yes, you can override the Setter and Getter for any attribute.
For example, the standard mORMot database userids store a hash of the password. You can set the password, and it is hashed before being stored, so you cannot read it back as plain text.
Erick
Last edited by erick (2016-12-22 03:09:03)
Offline
Yes, you can override the Setter and Getter for any attribute.
For example, the standard mORMot database userids store a hash of the password. You can set the password, and it is hashed before being stored, so you cannot read it back as plain text.
Erick
I'll check that out. What source file is that in?
Update: Never mind. I found it. That's normal property getter/setter behavior. I was asking about how to get between the model and the database.
-David
Last edited by DavidRM (2016-12-22 19:00:42)
Offline
Pages: 1