For my next flutter project,
Please suggest to me, which will be the best option to implement DB
Moor or ObjectBox
Thanks in advance
It mostly depends on the kind of data you'll be working with. Since the data I'm working with is all relational (stored in Postgres on the back-end) I use Moor. It requires some more setup to join and get the correct data together in the app, but the watch/StreamBuilder capabilities of Moor make it worth it for my use-case. If any data changes in the background, the UI will update accordingly.
If your data exists only within the app or your backend uses a NoSQL solution like Firestore, using NoSQL (Objectbox) to store the objects likely requires much less effort, and is probably preferred. See also this Moor FAQ remark about Firebase.
In the end, as with so many questions in computer science, the answer boils down to "it depends".
Note
I have worked with Flutter + Moor, I do not have experience with ObjectBox. I have worked with Firestore in combination with a React web app before.
Related
I am about to start a flutter project and coming from android kotlin I was looking for the closest database to room.
I have read about floor and hive.
Before spending hours using both to figure out which one to stick to, I was wondering what you suggest guys.
I don't want to use firebase since the data remain mainly on tve user's device.
If you are happy with room and Kotlin I'd say Floor is your best bet for Flutter. While I haven't used either, I have used other object mappers with SQLite as well as Hive.
Now Hive as non-SQL database is totally different from an SQL based database.
The problem I'm dealing with is performance issues when needing to perform multiple Firestore queries in order to reach a result similar to to joins in SQL.
In my Flutter app, which uses Firebase and Firestore, I use Cloud Functions for serving my REST API. My API is the only thing that actually interacts with the Firestore database, not the Flutter app itself. I was always taught to design apps like this (not allowing the client to interact directly with the database) and so continued with that approach.
A potential solution I've seen are the official Firestore plugins for Flutter and have seen people designing their clients to interact directly with Firebase, however I haven't found any official documentation explicitly saying this design is preferred or even ok, and since it goes against when have been taught I haven't tried it yet. Can anyone confirm this or point me to documentation confirming this?
Edit
Perhaps it's worth noting that the reasons I've been told not to have the client connect directly to the database are 1. Security and 2. It would require business logic for managing data to be in the client and that should be handled server-side.
I'm a beginner programmer on the dart and flutter. I want to create an app to manage my small shop and save data on a physical device. I searched for any code samples, but I couldn't find anything. Any ideas or suggestions from Flutter professionals to begin my project will be really helpful.
You can either use sharedPrefernce plugin for storing data. But data may be persisted to disk asynchronously, and there is no guarantee that writes will be persisted to disk after returning, so this plugin must not be used for storing critical data.
Another option is Hive fast key-value database written in pure Dart.
you can also explore other options like sqllite or firebase_database
flutter create appname - This can be used to create flutter app
So, I am trying to create a project where I am supposed to Call Web API and store the data in my local storage. Which should still have even if the app is killed and then re-opened.
FYI, data will be large and I will require a significant amount of space in the mobile device.
i will be using firebase for login, the payment transaction and etc.
this is my first answer, I hope to help you.
BloC & Moor are not synonyms, BloC is a reactive state management solution that allows you to better manage the interaction between logic and widgets in a reactive way. Moor is a layer between sqlite and your application, it allows you to deal with sqlite using dart code by reacting to database changes through Streams and Futures
I think you do not need to choose one of the two, if your application is going to handle large amounts of data and will grow exponentially I recommend that you implement both as they complement each other, by designing a SOLID structure.
I've prototyped an iPhone app that uses (internally) SQLite as its data base. The intent was to ultimately have it communicate with a server via PHP, which would use MySQL as the back-end database.
I just discovered Google App Engine, however, but know very little about it. I think it'd be nice to use the Python interface to write to the data store - but I know very little about GQL's capability. I've basically written all the working database code using MySQL, testing internally on the iPhone with SQLite. Will GQL offer the same functionality that SQL can? I read on the site that it doesn't support join queries. Also is it truly relational?
Basically I guess my question is can an app that typically uses SQL backend work just as well with Google's App Engine, with GQL?
I hope that's clear... any guidance is great.
True, Google App Engine is a very cool product, but the datastore is a different beast than a regular mySQL database. That's not to say that what you need can't be done with the GAE datastore; however it may take some reworking on your end.
The most prominent different that you notice right off the start is that GAE uses an object-relational mapping for its data storage scheme. Essentially object graphs are persisted in the database, maintaining there attributes and relationships to other objects. In many cases ORM (object relational mappings) map fairly well on top of a relational database (this is how Hibernate works). The mapping is not perfect though and you will find that you need to make alterations to persist your data. Also, GAE has some unique contraints that complicate things a bit. One contraint that bothers me a lot is not being able to query for attribute paths: e.g. "select ... where dog.owner.name = 'bob' ". It is these rules that force you to read and understand how GAE data store works before you jump in.
I think GAE could work well in your situation. It just may take some time to understand ORM persistence in general, and GAE datastore in specifics.
GQL offers almost no functionality at all; it's only used for SELECT queries, and it only exists to make writing SELECT queries easier for SQL programmers. Behind the scenes, it converts your queries to db.Query objects.
The App Engine datastore isn't a relational database at all. You can do some stuff that looks relational, but my advice for anyone coming from an SQL background is to avoid GQL at all costs to avoid the trap of thinking the datastore is anything at all like an RDBMS, and to forget everything you know about database design. Specifically, if you're normalizing anything, you'll soon wish you hadn't.
I think this article should help you.
Summary: Cloud computing and software development for handheld devices are two very hot technologies that are increasingly being combined to create hybrid solutions. With this article, learn how to connect Google App Engine, Google's cloud computing offering, with the iPhone, Apple's mobile platform. You'll also see how to use the open source library, TouchEngine, to dynamically control application data on the iPhone by connecting to the App Engine cloud and caching that data for offline use.
That's a pretty generic question :)
Short answer: yes. It's going to involve some rethinking of your data model, but yes, changes are you can support it with the GAE Datastore API.
When you create your Python models (think of these as tables), you can certainly define references to other models (so now we have a foreign key). When you select this model, you'll get back the referencing models (pretty much like a join).
It'll most likely work, but it's not a drop in replacement for a mySQL server.