I am trying to add objects into firebase real time database, so far, i have been creating the same object for different parents. My question is how to save the same object in different parents. So far I am not saving with code, just in firebase console.
Pic to help understand.
This is the structure Pais>Belgica>Partidos>2>Estadio and this stadium is Spartak Stadium
And I want to add the same Stadium that is in Belgica into my Tunez>Partidos>Estadio>2 with out creating a new Object, is there a way to tell firebase that this object is the same as the on in Belgica. Thanks in advance.
There is no real way to relate something elsewhere in the database to
what you are doing unless you save it yourself in both places.
However, there is another option. Cloud Functions are extremely powerful tools and are fantastic for data consistency. You can take a look at some of the samples Firebase has put out there for just this instance:
https://github.com/firebase/functions-samples/blob/master/README.md
Related
I have a web background majorly with javascript, I have started learning Corda recently for project implementation and need guidance in this regard,
So our application is based on the web, the user signs up with different school name, create question papers, and then want to share either part of it or whole with teachers of some other school in our platform. they can make changes and assign it back to creator and the process goes back and forth, finally signing the paper to be finalized, once finalized it cannot be changed by anyone. I need to store these transactions in Corda application, not sure how to go about it, I did try replicating it using negotiation application in corda/kotlin/sample, but stuck in a bug as I was trying to send a list of objects.
I do have the following questions in mind
Should I use enterprise edition or go with open source as I think I need schema design for this. web db is in postgress
As far as I have seen each node is predefined in the config with username and password,is there a way to create the node while the user signs up.
I have schools and teachers inside the school, do I need a separate node for each school and then create states in each node(not sure if a node can be set up at run time). or do I use the account's library provided for creating the account of each teacher, if yes id there a way to use passwords in it, unable to find password field in it.
how do I send an array of objects to the state, or should I create a separate state for each question, as different questions can be assigned to different teachers, but again multiple questions can be assigned to the same teacher.
These are few questions on my mind any help is much appreciated, as most of the examples gave IOU samples or states with int and string, Please guide me in the right direction.
Alessandro has good advice here, definitely look at the samples repos for inspiration on how to build what you're looking for.
start with open source, it's easier to prototype and you can switch to enterprise later it won't be an issue for you
this depends on design, you wouldn't really want to create a new corda node per-person, you might want to have corda accounts that run on a single node instead. See accounts sdk here: https://github.com/corda/accounts
what you might do is make a corda node for each school and then accounts per teacher like you were already were thinking. That would mean only a couple of nodes based on the number of schools you have.
as long as your state is marked with #CordaSerializable you won't have problems sending arrays of data, I send an array in a state in this sample here: https://github.com/corda/samples-java/blob/master/Advanced/secretsanta-cordapp/contracts/src/main/java/net/corda/samples/secretsanta/states/SantaSessionState.java#L24
https://github.com/corda/samples-java
https://github.com/corda/samples-kotlin
for the technically-savy people out there. I'm building a flutter app with a firestore backend and I've been doing some research as to the best way to structure my models. Tutorials online show different methods and I can't figure out what's the best one as I want my app to be light but also use Firestore efficiently so it doesn't cost too much.
Those are the ways I've encountered so far:
Have model for the flutter object and another one for the firestore object. Everytime I get the data from firestore I instanciate a firestore object and map it into a flutter object or create a new flutter object and then have a listener there to update my whole app.
Have one model for the flutter/firestore object. Everytime I get data from firestore I need to instantiate it once. No mapping. I have a listener there.
Get the data directly from firestore without needing to instantiate an object and print the documents there, and have a streamprovider to get the data.
I'd really appreciate your help in structuring my app/project. Thanks.
I think you should consider all your requirements, technical and business. The definition of your architecture should entails this needs. If you rush to choose an architecture that in the future would be needed to be re-defined, then it could be more expensive.
Once you have considered this, then you should think in your architecture. Try to share your general workflow.
I want my app to be light but also use Firestore efficiently so it doesn't cost too much.
All the three options you have shared fit to your needs? Is there a step in your solution in which the steps of your three options would fail?
I think you should base the architecture more on your needs than in which is least cost.
Been playing around with adding state management to my application, and was hoping for a little clarification on best practices for organizing normalized data.
Based on the documentation in the Redux Docs a common pattern is to organize things like "authors" and "books" under "entities" inside your state.
However, most examples that I've come by doesn't fit this pattern. It seems as though a common practice is placing "authors" and "books" on their own inside the state rather than within "entities".
Just hoping to get some clarification on this, and an understanding of how to get "authors" and "books" within "entities" to fit the structure of the example docs.
I wrote that whole "Structuring Reducers" docs section, so I'm gonna say I'm qualified to answer :)
Putting all the different normalized data under an entities key is just a suggestion. If you prefer to put each item type at the top of your state tree, that's fine and up to you.
A number of my suggestions in the normalization docs pages are based off of how the Redux-ORM library organizes things. It generates a reducer function that defines all the "tables" for your different item types, so that reducer function usually becomes a slice in your root reducer (and is usually named either orm or entities).
For more info on using Redux-ORM, you might want to read through my "Practical Redux" tutorial series, which shows a number of techniques for using Redux-ORM, and demonstrates its usage in a sample app.
Consider an example data structure with nested items. ie: schools.classes.students
In the UI is used to add/edit/delete the students only.
Do I connect the firebase Ref at the root (schools) or classes and get the UI to iterate over and manage the the data or does each student have a dataRef as this is where the data will be changed?
If each student has its own Firebase Ref (lets say 100 students), does this add any performace/latency issues?
I can explain further if needed but wanted to keep post short.
Firebase is intended to be used with large numbers of references and callbacks. Creating a reference ("new Firebase(...)") is an extremely lightweight option, so you should feel comfortable doing this very often.
In your app, usually rendering and network activity are the major bottlenecks, so loading and re-rendering large chunks is likely to be slow. I'd recommend accessing Firebase in a very granular way, and tying it tightly to your GUI so that only the minimum set of GUI elements need to be re-rendered when things change.
If this wasn't clear, please provide some example code and I can make some additional recommendations.
[I work at Firebase]
How do you access a Meteor collection that already exists? It's easy enough when you have created the collection in the session because you have a variable that references it, but you can't access a collection by name.
What happens if for example you want to retrieve documents from an existing collection in a new session where it is not being created for the first time. I have tried to 're-create' it hoping that it would just assign the existing collection to the new variable name (seeing that I can't find it by name), but it just throws an error to tell you that the collection already exists.
I've got some externally generated collections that I'm accessing via meteor. I'm not 100% sure that this will answer your question, but I hope it'll at least help.
One gotcha (doesn't apply to you it sounds like, here for completeness) is that if your collection was not created by Meteor, you'll need to export an environment variable to point Meteor to your DB.
For example, if the following env. variable is exported in the shell:
MONGO_URL=mongodb://localhost:3002/foo
...and then you invoke the meteor application, it'll point to the db "foo" in MongoDb, at which point you simply defined your collections as #Akshat mentions above in his comment:
collection = new Meteor.Collection("fooCollection") // this lives inside the foo DB.
If you're dealing with collections that have already been created by Meteor, by default they'll be inside the meteor db, eg:
MONGO_URL=mongodb://localhost:3002/meteor
...and you should be able to simply hook into them the same way; by simply declaring your collection and using it as you would. No need to create, obviously.
It sounds like you're already doing this but for other newcomers like me: in cases like this it's really handy to use the console in Chrome, Firefox, etc. and do some inserts that way - you'll see where your data lands, or you'll see other good bits of information that will help you home in on the issue - console.log() has saved my bacon a couple of times.
At any rate, it's worth validating exactly where the Meteor app is pointing vs. where you think it's pointing. Your collections should be accessible and should Just Work...