You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many storages do not support nesting. Thus, a Struct must be flattened somehow. Currently, there's no consistent solution across the library:
:android-bindingsSharedPreferencesStruct serializes a whole field into a Base64'ed String if it is a Collection of non-string or is a Struct,
:sqlTable has Embedded and NamingConvention to allow embedding Structs into Structs,
:http has no support for passing Structs as query parameters or form fields and waiting for this issue resolution.
The proposal is to implement a separate Layout type (inside core :persistence) which will deal with structs and naming conventions, and provide some additional info like hasCollectionsOfStructs, hasMultiDimensionalCollections, hasCollectionsOfNullables etc, so storages could fail instantly and require additional info, if necessary. Inflating and flattening machinery follows Layout and moves to :persistence.
embedded could become automatic everywhere (since SQL-friendly API #32 seems to be good without relations and graph fetching machinery, thus there will be no 1-to-1, 1-to-N, N-to-1, N-to-M relations, only embedding) but we must receive NamingConvention somehow, thus the API question remains open. :sqltype() and nativeType() remain within Table as SQL-specific things. SharedPrefs and HTTP could support their own adapters for complicated cases.
The text was updated successfully, but these errors were encountered:
Many storages do not support nesting. Thus, a Struct must be flattened somehow. Currently, there's no consistent solution across the library:
:android-bindings
SharedPreferencesStruct
serializes a whole field into a Base64'ed String if it is a Collection of non-string or is a Struct,:sql
Table
hasEmbedded
andNamingConvention
to allow embedding Structs into Structs,:http
has no support for passing Structs as query parameters or form fields and waiting for this issue resolution.The proposal is to implement a separate
Layout
type (inside core:persistence
) which will deal with structs and naming conventions, and provide some additional info likehasCollectionsOfStructs
,hasMultiDimensionalCollections
,hasCollectionsOfNullables
etc, so storages could fail instantly and require additional info, if necessary. Inflating and flattening machinery followsLayout
and moves to:persistence
.embedded
could become automatic everywhere (since SQL-friendly API #32 seems to be good without relations and graph fetching machinery, thus there will be no 1-to-1, 1-to-N, N-to-1, N-to-M relations, only embedding) but we must receive NamingConvention somehow, thus the API question remains open.:sql
type()
andnativeType()
remain withinTable
as SQL-specific things. SharedPrefs and HTTP could support their own adapters for complicated cases.The text was updated successfully, but these errors were encountered: