Is it ok to save all fields of an entity as a string if it should not be changed?

Question

I have a complex object that has several fields can be updated until it is locked.

Is it proper to save this locked entity as another entity which has no object child, only string data.

complex object

{
 Student student;
 Teacher teacher;
 Address address;
 //...
}

after it is locked. this information will never change. it should not be updated. So is it ok with that if i save it another entity like

flat complex object

{
 String studentName;
 String teacherName;
 String addressName;
 //...
}

this is a pseudo example, please do not stuck on logic.

Is it proper or better way like xml, json, document db etc..?

• Bart van Ingen Schenau: Is there any part of your code where both locked and unlocked entities need to be dealt with? Or maybe even a mixed list of them?
• AhuraMazda: A list of complex object locked by admin. After that locked object will never change again. it will only be read only. Locked and unlocked entities have not common point.
• AhuraMazda: In addition, if I save complex object as relational object, I cannot guarantee that the child objects will not change. But i definitely want to store locked object as it has locked.
• Laiv: How does serializing complex objects into strings make this data immutable in the data store? Is the data stored encrypted somehow? I mean, once in the database, you can change these values with an update operation. The real question to me should be does it worth coding a business rule this way? Do the pros outweigh the cons? Will 8 different objects (which are the same thing but they aren't interchangeable in runtime) make code easier to reason about? Easier to maintain? More readable maybe?
• AhuraMazda: 1-Flat object will not be immutable or encrypted. I will prevent this object from being updated programatically.

Answer 1

Disclaimer: I took the freedom of changing some words and expressions to make the following summary comprehensible. Also, note that OP's meaning for locking is rather "invariable". All the model is updatable, but after certain events, some data must remain as it was at the moment of the mentioned event

To sum it up

I have a complex object that has several fields that can be updated until it is locked. ^{[Assumption of mine]: These fields correspond with other entities that can change at any time}

My main purpose is that student objects can be changed, but I don't want [locked data] to be affected by these changes.

It is ok [if] the student's name changes but [locked data] should [remain as it was by the time it was taken].

Ok, I think it's clear now.

Yes, it's reasonable to make a projection of the former data (complex object) and store it as a new row in a different table. Or in a different database or system.

Edit: Note that, the new model, can hold the IDs of each entity involved (for further correlations). The key then is not mapping these IDs with their original entities in your persistent layer (ORM). You keep them as raw data

Is it a proper or better way like XML, json, document db, etc..?

We can't say. This is something specific for each project. You are the only one who knows what happens with the locked data and who is granted access. The solution should come motivated by real needs, not only by "immutability". You could persist the data into a NOSQL DB but it doesn't make it immutable per se. You could store data in files and protect files with file system grants, but then accessing and querying seem complicated.

Your project is enclosed with a superior purpose. A business strategy. The decision should be aligned with this purpose in such a way that makes the business strategy possible and affordable.

• AhuraMazda: Thanks for replying. "projection of the former data" is keyword for me. This is what exactly i want. I asked question because of "do not break object oriented approach" taboo.
• Laiv: Note that, you can achieve the same result in many ways. Even with OOP. I assumed you already made a decision so I didn't want to mess with polymorphism, inheritance, patterns, etc. Regarding OOP, @candied_orange's answer, despite not hitting the nail, it's not far from reality. You could have achieved the same result by turning those complex objects into immutable programmatically.

Answer 2

I think you've smushed together some concerns that sound like they're related that really aren't.

Is it ok to save all fields of an entity as a string...

Sure, provided you have some method of converting those strings to the form you need when you load those fields into memory again.

... if it should not be changed?

Huh? Sure string objects are immutable in most languages but that only limits what you can do to them once loaded into memory. It certainly doesn't protect them after you save them to your hard drive.

I have a complex object that has several fields can be updated until it is locked.

Oooh I know this one. It's called the Freeze Thaw Pattern. It's a bit obscure but might be worth a look. But again this only protects while in memory, and only from honest programmers.

So is it ok with that if i save it another entity

Well like the tag says an entity:

An entity is an object or a set of data that has an identity that persists changes of its attributes. In an object oriented context, it usually refers to long-lived information relevant for the stakeholders of the system.

Our entity tag

Entities are meant to change. Only their identity is guaranteed not to. What you can do is take an entity at one point in time and copy it into an immutable value object. But doing that has nothing to do with making the fields into strings.

When copying an object there are two different ways to do it. A shallow copy or a deep copy. A shallow copy of object A (that points at B) gives you a new copy of A (that points at the old B). A deep copy of A gives you a new A pointing at a new B.

You run into this problem when serializing all the time because the address things live at is only meaningful when they are in memory. Save them to a file and that context is removed. So saving usually requires making a deep copy.

There are two ways to deep copy to a file. Point A to where B is located in the file knowing that you'll have to translate that back on load, or put B inside of A.

It looks like you're getting ready to put B inside of A while it's still in memory (the 'flat complex object'). You can do this but the intermediate class of strings isn't really needed. Just some way to get B to tell us how to serialize it. If B can be represented as, and loaded from, a string you can stick it in A using xml or json or the like.

Maybe you don't want B to know how to serialize itself. Maybe you want to make something else figure that out. That's possible as well. B and the serializing code need some way to communicate, even if it's just through reflection.

What a lot of coders get hung up on is the idea that saving should be easy. It's not. You're dragging your stuff from one context and shoving it into another. Doing that right is work. Don't underestimate it.

• AhuraMazda: When I say not changeable object I mean user cannot change object. It is not related with being immutable object. So if I keep object in database as a relational object, child object like Student name can be changed by some other users. It is ok that student name change but my locked complex object should keep student name same as it is locked. I added some addition information below my question. For example, I want to keep some billing information,it is critical that information in billing will never change. why we keep these information relational?Is that not proper to keep all fields string
• Laiv: Ok. Are you, maybe, thinking of some kind of snapshot of the relational data at a given moment in time?
• candied_orange: A student stored in a relational DB is typically stored in a row. Not an object. And if you mean only certain users can change a students name then you need a permission system. Still has nothing to do with strings.
• AhuraMazda: @Laiv you are totally correct. I want to take snapshot of complex object having many nested object to easily read from ui.
• candied_orange: Well now it sounds like you want one system to have a read only relationship with the DB. I doubt you’re going to get the answer you want when what you mean is scattered in comments like this.

Answer 3

Both internal and external representations of data are irrelevant to what you want to do, they are relevant to how easy and efficient it is to do what you want to do.

Languages and how your data is stored and manipulated does not affect what you can do (see Turing Complete). They obviously affect you implementation and how much effort you have to put into it to get the results you want.

Change isn’t allowed or prevented because the data is stored in a particular way, change is allowed because a program is designed to allow it, and it is prevented by not including that as part of the design.

Likewise for external storage, it is not having data stored on a write once drive that makes the data unchangeable, what makes it unchangeable is the policy on how those drives are handled, if policy allows swapping one write once media with another with different data on it, that becomes the applications new source of truth and the data has been changed.