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
{{ message }}
This repository has been archived by the owner on May 24, 2023. It is now read-only.
For now, sets are only snapshots of the data source matching a precise query, but this approach lacks of possibilities to actually manipulate data persisted in store through a set or operate on the set content
Read
Some methods, such as find, findMany, or upcoming has, count or every methods (see #25) would be useful on Sets too, to perform checks or filters on already retrieved sets.
Create
It would be useful to allow the user to manually add arbitrary entities to a set without persisting the insertion. To persist at the same time that we add items, maybe we should also offer the possibility to insert items in the set and in the data source, but it may be redundant with an add followed by a persist of the set.
Update
Update is OK IMO:
To update some entities of the set, we can directly edit them then persist:
To update all entities of the set, we can use the update method, optionaly followed by a persist call.
Delete
For now, we can only change the collection of entities in the set by modifying the entities property, which should be readonly by design. Filtering entities from an existing set is pretty important to keep the code clear and concise, as well as optimizing by doing several different operations on different sets extracted using a single data source search.
Seeing that, the set may evolve in a class implementing both interfaces defined by adapters (like insert, insertMany, has, all, count, etc etc) and entities (such as persist, destroy and fetch). So, maybe we can re-manipulate the set to be a special kind of temporary in-memory data source. Of course, most of the new features described above can be done using the lodash wrapper returned by the toChainable method, but it requires extra method calls and lose the ability to use the Diaspora's query language
As seen with @IkarosWilo yesterday, the Set can be interpreted as a collection with querying methods (defined above) and using a temporary in-memory store. The Model is just a Set that replaces its adapter with the one configured by the model description, and with an associated entity factory
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
For now, sets are only snapshots of the data source matching a precise query, but this approach lacks of possibilities to actually manipulate data persisted in store through a set or operate on the set content
Read
Some methods, such as
find
,findMany
, or upcominghas
,count
orevery
methods (see #25) would be useful on Sets too, to perform checks or filters on already retrieved sets.Create
It would be useful to allow the user to manually
add
arbitrary entities to a set without persisting the insertion. To persist at the same time that we add items, maybe we should also offer the possibility toinsert
items in the set and in the data source, but it may be redundant with anadd
followed by apersist
of the set.Update
Update is OK IMO:
update
method, optionaly followed by apersist
call.Delete
For now, we can only change the collection of entities in the set by modifying the
entities
property, which should be readonly by design. Filtering entities from an existing set is pretty important to keep the code clear and concise, as well as optimizing by doing several different operations on different sets extracted using a single data source search.Seeing that, the set may evolve in a class implementing both interfaces defined by adapters (like
insert
,insertMany
,has
,all
,count
, etc etc) and entities (such aspersist
,destroy
andfetch
). So, maybe we can re-manipulate the set to be a special kind of temporary in-memory data source. Of course, most of the new features described above can be done using the lodash wrapper returned by thetoChainable
method, but it requires extra method calls and lose the ability to use the Diaspora's query languageComments welcome, @IkarosWilo
The text was updated successfully, but these errors were encountered: