client-side persistent data.

[Sander Elias]

Hi,

I was wondering how far the support for client-side storage in NG2 has settled? Are there plans at all?

Regards

Sander

[Benjamin (Inglor) Gruenbaum]

What did you have in mind?

--
You received this message because you are subscribed to the Google Groups "angular-data-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular-data-d...@googlegroups.com.
To post to this group, send email to angular-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angular-data-dev/5052f68e-342d-4d67-b433-71e53c737257%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sander Elias]

Hi Benjamin,

Well, I think we need 2 things.

Lets start with the first one. We need a simple key-value store, most ideal, with a namespace. Something to replace local storage, and storage-cookies.

this all should be drop dead simple to the developer:

• save to (namespace, key, value)
• restore from (namespace,key)
• delete (namespace,key)
• namespaces should be optional.
• Save and delete should trigger an event to other windows using the same namespace.
• easy way to retrieve and store a whole namespace. (to, for example enable easy sync with back-end)
• using the previous to overwrite an entire namespace should also trigger an event to other windows.
• preferable all wrapped in observables. 

The second one, does all that, but not for key-value pairs, but for records/objects. Think address books, inventory items, and other organized stuff. It would be great if it would cater for 1-n and n-1 relations too.

Regards

Sander

[Jeff Cross]

Hey Sander,

As of now, we our approaching this in two ways. The first approach is to provide wrappers around native APIs (IndexedDB, localStorage, sessionStorage) to improve the usability and testability of the native APIs. The 2nd approach is to work with third-party libraries who are solving these problems at a higher level, by providing feedback to the libraries, and by making sure angular core can easily work with these libraries. 

Alex Rickabaugh and I are actively doing research right now to explore what additional tooling we should build and support as part of core angular, so your input is appreciated.

One interesting project that I've worked with is Lovefield, which is a SQL-like database built on top of IndexedDB. I believe it solves all of the problems you've enumerated, though it is heavily promise-based at the moment. The project is rapidly-evolving, and is maintained by googlers: https://github.com/google/lovefield

[Sander Elias]

Hey Jeff,

Before digging into the details, I made an document, mostly to put order my own thoughts. It is an WIP. 

Perhaps that document is a better place to work this out further?

I have looked into Lovefield a few months back. It was not ready for use back then. (not for my use at least!) I really like the idea. However I have 2 serious concerns.

1. synchronous? This is a bad idea in my opinion. I understand where this is coming from, but that does not make up for it. The short reason I dislike sync, is that it makes it really hard to switch between local and remote data. Both should have an similar interface!
2. promises? (refer to other threads here ;) )

I hope to hear your opinion on the document soon,

Regards

Sander

[dpapad]

Hi Sander,

I am one of the maintainers of Lovefield library. Just wanted to clarify that Lovefield querying API is asynchronous. Did something in our docs made you think it is synchronous? Regarding promises, I have not read any of the other threads you are referring to, so can't really comment on it, besides the fact that we chose promises since it is the only standardized way to do async (and we have workarounds for browsers that don't natively support promises, like IE).

  As far as having a uniform interface, Lovefield supports officially two different backing stores, Memory (no persistence) vs IndexedDB. Regardless which one is used the user is interacting via a common interface. We also have an experimental remote backing store using Firebase (but this part is not ready for production use, need to sort out some issues with the Firebase team).

Thank you, and feel free to ask any question on Lovefield.

Demetrios

[Sander Elias]

Hi Demitrios.

I didn't mean to offend you, or lovefield. Sorry if that happened. I think it is a very good product, which has broad use cases.
First of all, I just did read trough your docs, I have no working knowledge of lovefield. I based my opinion on the synchronous on the last paragraph of this page.
Then there is are the promises, in a few other threads we just had a long conversation of why observables are better suited for the communication part. A lot of that conversation holds firm when applied to PLD(persistent local data).

I do like lovefield, but I firmly believe that with NG2 we have a change to do even better. the 2 points I observed are in that setting, and not to talk lovefield down. Perhaps you get a better perspective if you read trough the document I linked in my previous msg.

Thanks for your reaction, and if I'm mistaken in my opinion, please correct me. If the information in the API Style part is outdated or just plain wrong, will happily reevaluate my standpoint!

With kind regards

Sander Elias

[dpapad]

No problem. I was not offended at all, just wanted to make sure that there is no error in our docs that misleads developers. I will take the

time to read the document you refer to get more context. But my short comment regarding promises vs observables is that they serve

different use cases.

  When an event is linked to a specific action (request/response) there is always a 1:1 mapping and those cases are served better

with promises. Request/response can be for example either HTTP request -> HTTP Response, or in case of Lovefield a database query -> response.

  Observables make more sense when events happen that are not linked to a specific action (or such actions are taken by other entities like

background tasks etc). Having said that, Lovefield also supports observers, in the sense that you can observe a given query, and whenever

this query's results change you get notified (without having to manually ever re-run that query).

Thanks again, and by no means I was offended.

Demetrios

[Sander Elias]

Hi Demitrios,

But my short comment regarding promises vs observables is that they serve different use cases.

No argument here. Promises sure have there use-cases.

 

  When an event is linked to a specific action (request/response) there is always a 1:1 mapping and those cases are served better with promises.

We are not in agreement here. An 1:1 mapping is just as easy to use with an observable. Then there is this, data is dynamic by nature. it can change anytime. Promises are static representations of that. Observables are live representations.
There are a lot of practical use cases that are more easily solved with observables here. Observables are easily converted into promises, so when a use-case for promises is there, those can be used too. 

 

 

Lovefield also supports observers, in the sense that you can observe a given query, and whenever this query's results change you get notified (without having to manually ever re-run that query).

Good to hear this. This should be default behavior most of the time.  When a result set is a observable array of observables, it can keep itself up-to-date all the time. (if you display it in the view, it will auto-update, on every data-change)

And yes, this is turning over a lot of complexity to lovefield, but that is where it belongs. Right? ;)

Regards

Sander

[Benjamin Lesh]

Oh no, not this discussion again. :p

--
You received this message because you are subscribed to the Google Groups "angular-data-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular-data-d...@googlegroups.com.
To post to this group, send email to angular-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/angular-data-dev/deafde03-aaba-432b-8577-3e307003fb0d%40googlegroups.com.

[Jeffrey Cross]

Haha +1 what Ben said.

To view this discussion on the web visit https://groups.google.com/d/msgid/angular-data-dev/CADcN1GAmzM-_7ZZQ6mVuGZmCS-Ha1%2BcCv3-KWWBOowLu89gFYg%40mail.gmail.com.

[Sander Elias]

@blesh. You made me laugh :-)

@jeff, Ok, I hear you.

I promise, I won't repeat all the moves again. (at least not in a public form), that said, I think the subject is important enough not to ignore! 

@demitry: to get the reference, see this and this thread. If needed I can go on on it ;) (but in private mail!)

[Arthur Hsu]

I'm the team lead and spec owner of Lovefield. Thanks for the interest of the library, and there seems to be some more confusions about how Lovefield is designed, so allow me to spam this thread a little bit more.

Lovefield has DDL-ish APIs (schema definition) and DML-ish APIs (queries). All queries are performed asynchronously and return Promises. On the other hand, schema definitions are synchronous, since it makes very little sense the other way. Lovefield is designed to interoperate with major JS frameworks and it shall work with future Angular versions regardless of the async primitives chosen by Angular.

Some more comments inline.

On Fri, Apr 24, 2015 at 9:34 PM, Sander Elias <sande...@gmail.com> wrote:

Lovefield also supports observers, in the sense that you can observe a given query, and whenever this query's results change you get notified (without having to manually ever re-run that query).

Good to hear this. This should be default behavior most of the time.  When a result set is a observable array of observables, it can keep itself up-to-date all the time. (if you display it in the view, it will auto-update, on every data-change)

And yes, this is turning over a lot of complexity to lovefield, but that is where it belongs. Right? ;)

Since you're very influential, I need to say something here before other users pushing for this requirement again :) Observable queries in Lovefield are relatively expensive performance-wise. The users should treat them as RDBMS TRIGGER and use wisely. From the API designer point of view, I would not set it by default to prevent the users from shooting their own feet too easily. You're more than welcome to discuss this topic further on Lovefield's own discussion group https://groups.google.com/forum/#!forum/lovefield-users.

 

[Sander Elias]

Hi Arthur,

Lovefield has DDL-ish APIs (schema definition) and DML-ish APIs (queries). All queries are performed asynchronously and return Promises. On the other hand, schema definitions are synchronous, since it makes very little sense the other way. Lovefield is designed to interoperate with major JS frameworks and it shall work with future Angular versions regardless of the async primitives chosen by Angular.

Thank you for clarifying this. That makes the sync/async thing an non-issue.  

I think I will need to dig into lovefield, and wrap it up with some observables to see how severe the performance issues are. I probably will have an question or 2 at your group!

Regards

Sander