Is there a way to add a field to an entity that s lazy Meani

Question

Is there a way to add a field to an entity that s lazy Meaning I don t want it loaded unless I ask for it in a select < Toshihiro Nakamura>

Toshihiro Nakamura · Answer

Komapper does not have a way to retrieve data for a particular field lazily However it is possible to achieve similar results by splitting entity classes for example

dave08 · Answer

You mean making another entity class for the same table

dave08 · Answer

That wouldn t be so nice for schema generation But I guess possible

Toshihiro Nakamura · Answer

gt You mean making another entity class for the same table Yes Alternatively you could treat the data type of that field as a Blob or Clob

dave08 · Answer

Yeah but it could be nice to have a ` KomapperLazy` or ` KomapperColumn lazy = true ` then it wouldn t be included in the select when loading the whole object and it would have to be nullable to indicate it wasn t loaded then only if specified specifically in the field list in select would it actually be loaded it would allow to use that field in a type safe way in where s inserts etc w o having to load it

Toshihiro Nakamura · Answer

Thanks for showing me your idea However I will not implement lazy loading in Komapper as it tends to cause problems

dave08 · Answer

It s not really lazy loading I mean once the query is run you can t access that field lazily it s really like ` KomapperIgnore` but the difference is that it s a real field that is generated in schema generation and can be used in queries

dave08 · Answer

Maybe my naming is a bit wrong

dave08 · Answer

But I don t want to retrieve every field in my entity definition

dave08 · Answer

maybe it would also be ok to have an `excludeFields` in the querydsl but it would be a bit less convenient

dave08 · Answer

Would this cause problems < Toshihiro Nakamura>

dave08 · Answer

The only thing is representing the field when it s missing from the query if it s nullable in the data class and not in the table it might not be so great

dave08 · Answer

Now that I think of it this could be possible with an AlternateMapping a value class could represent it as a Nothing but the mapper would not actually retrieve it that would work no

dave08 · Answer

The only problem would be when I actually need to retrieve it

dave08 · Answer

But for using it in queries it should work

dave08 · Answer

Or maybe I can create my own PropertyMetamodelImpl for the field to use it in queries < Toshihiro Nakamura>

dave08 · Answer

In that case it might be enough just to have some kind of utility function to do such a thing for these kind of needs they could even be defined as extension function on the model then there wouldn t be any problems of initializing them

dave08 · Answer

`val MyEntity address by lazyField address `

Toshihiro Nakamura · Answer

gt excludeFields in the querydsl This idea is OK But wouldn t having two entity classes for one table be simpler

dave08 · Answer

No it would mean unnecessary duplication the only problem with that is how to represent the missing value in the data class What do you think about my lazyField extension property idea

dave08 · Answer

It might even be possible to include it in generation but it could only be used in queries not actually retrieved unless retrieving individual fields

dave08 · Answer

Maybe not lazyField but `virtualField` or just `by field` and the fact that it s a val and just an extension property already indicates it can t be retrieved

Toshihiro Nakamura · Answer

Can you show an example implementation of the lazyField extension How do you intend to perform an INSERT or UPDATE on that field

dave08 · Answer

It would be an extension function from the `Meta` object not the actual entity I got confused at first and the same way you d use a regular Meta definition

dave08 · Answer

The entity itself could maybe have it just as a placeholder to allow the generation to work like a ` KomapperIgnore` and for schema generation

dave08 · Answer

But it wouldn t be included in creation maybe it would be in the class definition NOT the constructor

dave08 · Answer

Another idea would be to have two constructors one with the field and one w o for the user to decide what to do when the field is NOT excluded

Toshihiro Nakamura · Answer

I may not fully understand your idea It would be great if you could show me more code

dave08 · Answer

1 ``` KomapperEntity data class Person KomapperVirtual val address String would create that field in the db but not retrieve it by default```

dave08 · Answer

2 ``` KomapperEntity data class Person KomapperVirtual val address String constructor w o address this adresss = null would create that field in the db and allow using all fields including address or just the fields in one of the alternate constructors then the user would contiously decide what to do to initialize optional fields maybe a constructor could be annotated to help komapper resolve the right one in the query dsl val person = QueryDSL useConstructor ```

dave08 · Answer

The first idea would only provide the ability to use fields that don t need to be retrieved in queries the second would actually allow to optionally retrieve them which is probably more complicated to implement

dave08 · Answer

It could be that instead of creating a new annotation it might be enough to reuse existing ones like ` KomapperColumn` since it would be distinguished by the fact that it s not in the constructor

Toshihiro Nakamura · Answer

Thanks for sharing the code I understand that by default you do not want to get the value of the address property But when you really need it how are you going to get it

dave08 · Answer

Just with a `select ` and get it as a value like this <https www komapper org docs reference query querydsl select select> but it won t be in an instantiated entity object

Toshihiro Nakamura · Answer

``` KomapperEntity data class Person KomapperId val id Int KomapperColumn autoSelect = false val address String = null ``` What do you think about the idea of adding an `autoSelect` property to ` KomapperColumn` If this property is set to `false` Komapper will check that the default value is specified for the annotated parameter at compile time

dave08 · Answer

The only problem with that is how will you differentiate between nullable fields and such defaults when generating schemas

dave08 · Answer

That s why I proposed it NOT to be in the constructor or to have an alternate constructor for such cases that the field isn t requested then in the query the user would need to specify which constructor to use somehow

dave08 · Answer

This is an important feature now that I m in production because this field is very big and I don t really need to retrieve it s contents only to query it or save to it in an update statement

Toshihiro Nakamura · Answer

If you create two constructors that is almost the same as creating two entity classes Therefore I still recommend making two entity classes ``` KomapperEntity data class Person KomapperId val id Int val name String val age Int KomapperEntity KomapperTable PERSON data class PersonAddress KomapperId val id Int val address String holds large data ``` The second class should only have an ID and a large field

Toshihiro Nakamura · Answer

Ideally the person table might be split into two

dave08 · Answer

In the end that s what I did but it does complicate working with Komapper for I think what is a pretty common use case

Toshihiro Nakamura · Answer

gt maybe it would also be ok to have an excludeFields in the querydsl but it would be a bit less convenient I see Then how about achieving it with QueryDsl as you say For example ```val p = Meta person val query = QueryDsl from p deselect p address defalt value ``` The second argument of the `deselect` function is passed to the constructor of the entity

dave08 · Answer

That would be a possibility but it wouldn t express the case where the user is only including the field to be generated in the Meta object and in schema creation say in a case where that field is NEVER included when retrieving the whole entity class like in my case

dave08 · Answer

Then there would be extra boilerplate in every query to explicitly exclude it

dave08 · Answer

In my case that field is a sort of history that I write to but I don t read from it

Toshihiro Nakamura · Answer

The best solution in your case would be to split the table in two

Toshihiro Nakamura · Answer

gt Then there would be extra boilerplate in every query to explicitly exclude it You can reuse a query to reduce boilerplate ``` define a query once val personQuery = QueryDsl from p deselect p address defalt value reuse the personQuery val query1 = personQuery where p id eq 1 val query2 = personQuery where p age eq 40 orderBy p id ``` You might as well use an extension function ``` define an extension function fun lt ENTITY Any ID Any META EntityMetamodel lt ENTITY ID META gt gt QueryDsl fromPerson SelectQueryBuilder lt ENTITY ID META gt val p = Meta person return QueryDsl from p deselect p address defalt value use the extension function val query = QueryDsl fromPerson ```

dave08 · Answer

So I guess it s much harder to implement what I was suggesting before then thanks anyways

dave08 · Answer

You ve already done tons to make this library so nice