Skip to content
This repository has been archived by the owner on Aug 31, 2022. It is now read-only.

I take it that there is no support for embedded objects (e.g. value objects)? #63

Open
purpleP opened this issue Oct 20, 2015 · 6 comments

Comments

@purpleP
Copy link

purpleP commented Oct 20, 2015

Very often there is need to store with Entity some value objects. JPA provides means to do that. I can't find anything about that is SORM documentation. It's a shame when I need to save every value object to database, before actually assigning them to the Entity (or to deconstruct this value object into primitives).

@nikita-volkov
Copy link
Contributor

If the support for composite types is what you're talking about, then there's no support for that.

@purpleP
Copy link
Author

purpleP commented Oct 20, 2015

Yeah, I'm talking about composite types. Maybe you could implement them? I don't know much Scala, but probably could try too if that's not completely against your framework philosophy.

@purpleP
Copy link
Author

purpleP commented Oct 20, 2015

Its bad for performance you know and to deconstruct composite values into primitive types is not a good practice also.

@nikita-volkov
Copy link
Contributor

I'm not going to implement this. From the first glance I don't see anything being against the framework's ideas in this. However I expect there to be problems with DB support. Postgres has composite types sure, but what about the other backends, which SORM claims to support? So it's a matter of a compromise.

If you're writing a performance-critical application I would strongly advice against using any kind of ORM and go for SQL directly.

@purpleP
Copy link
Author

purpleP commented Oct 21, 2015

I don't think that you need DB to support composite types. It's just about the framework being a little smarter in mapping. For example

case class Account(internalId: Long, balance Money)

case class Money(double amount, String valuteCode)

The framework could see that Money class could be flattened and is a value object.

So it should create one table Accounts with columns: internalId, amount, code.

In JPA its done by annotations or in configuration by @embeddable and @Embedded annotations.

@nikita-volkov
Copy link
Contributor

That could be done, but introduction of annotations will ruin the isolation of DB logic. I don't like such an idea. It probably would be okay to implement this as part of the DB instance configuration, but then I won't be doing this either way. If someone dares to take over - sure.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants