I'm making a firebase app where there's the concept of posts and authors.
I need to have a field called postedBy to give information about the post author. I'm currently confused on how to best implement this. Here's what I've thought about...
Store a postedBy field with the post author's ID as value. My issue with this is that I have to further send single requests for the user information, like name, profile picture etc.
I store a postedBy field with the exact clone of the author's data (name, profile URL, etc). My issue with this is what if the user changes their profile information? Do I have to loop through all the posts data to also ensure the changes?
What is the best way to solve an issue like this?
For your case, I would say that the best option would be probably to use only the ID as a value. This way, you can perform queries to return values using only the ID.
Using this approach should be the simplest and easiest way for you to create your application. Since the ID will be the point to connect your tables and to perform the queries, it should make your work easier.
In the below article, there is an example of a Blog application, that you can take a look and get some insights on how to configure your application as well - mainly about this part about author and post. :)
Learning Firebase: Creating a blog article object
Let me know if the information helped you!
Related
I want to develop a job board website. I want specific feature in that is job posts will be created automatically by email parsing.
I tried Zapier, but it creates only blog posts.
And tried postie plugin to, but Gmail didn't allow it.
Willing to use job monster / work scout/ superio any one of these themes. If you have any suggestions, please let me know about it.
Is there any way to parse the email data and create a new job post. Please help me to resolve this issue.
No paid task. Need help to learn the things
There is a lot to unpack here.
The main problem you are going to encounter is that the emails you are parsing may not all be formatted the same. To pull the info out of an email you will need to be able to generate some rules to extract it.
If however, the emails are formatted the same then you can use the "split" function in Zapier to pull out the various bits of data from the email. Once you have these you can create a new post with your Zap.
I would recommend looking for a Wordpress plugin that allows you to create lists with custom post types. WP-Bakery does this from memory. You can set up a custom feed based on that post type.
Hopefully this helps narrow down the process for you. Good Luck.
I am working on existing concrete5 website and I don't have sufficient knowledge of concrete database structure.
I am creating api to fetch all the products which are added in "Stacks and Blocks".
I have cID, stID values and fetched the info from stacks table, Can anyone please let me know How to fetch the complete details including image from database.
I tried to make the relation between tables based on cID, stID.
Thanks in advance.
The images are stored in the application/files directory although you'll need to retrieve the path from the database to find them. as #1stthomas noted, without more details of the information you are working with, it's difficult to provide any specific advice.
FWIW, the API documentation for concrete5 can be found here.
I'm trying to use the "orderByChild" functionality provided by Firebase, but I stumbled upon a roadblock. The structure of my database is very simple, it looks a bit like this:
Root
Users
${UID}
ID
Name
Birthday
...
Now, I'd like to search other user's names without knowing their UID.
Does anyone have an idea on how to solve this problem?
I could just download the users file completely but that does not seem like a good idea.
this about the question before posting it on stack overflow : you have to make a strategy to get this issue solved , I propose to you two possible solutions :
1)(very bad solution):
you parse the data from firebase and you put them in [<String , anyObject>] and you loop over this array in order to get the username that you want to get.
**
Ps: in term of performance and usability the worst thing that you
could do is to invoke the database to get unuseful data, so don't use
this solution in production.
**
2) you make a strategy for this:
look over what should be the relationship between a user and another and add new field for example friends and store on it the uids that you want to get.
http://www.silverstripe.org/archive/show/1638
The above post seems like it's what I should do but I just need some help sorting this out in my head.
Firstly, I need to create a relationship between a page (Owner, for example) and a dataobject (Car). An owner can create many cars which are linked to that one owner. However, I have another page (Garage) which can create cars that are linked to every owner. If an owner does not want one of these cars they reject it. I was thinking the manymanydataobjectmanager would be good for that bit.
Each owner should only be able to see the cars that relate directly to them within the CMS, not other peoples cars, so I was using dataobjectmanager and assigning permissions to the page using groups.
The thing that is really making this awkward is that when it's all set up I need to output JSON which will consist of the cars the owners created and the cars they accepted from the garage, not the ones they rejected. I'm thinking I need another table like the linked table but with a status column perhaps?
To clarify, my question is how do I create this mess in a constructive SilverStripe way? Is the approach I was taking correct or is there a better way?
Many thanks in advance and please tell me if I've been unclear.
are you using silverstripe 3?
could you clarify what of the actions happen in the backend and what actions are possible for the user in the frontend?
maybe for your relations it could be better to use ModelAdmin:
http://doc.silverstripe.org/framework/en/reference/modeladmin
It gives you the opportunity to manage relations without the Sitetree/Pages Overhead. For example creating a Sitetree Element just to have an Owner is not the best way - except if you really need an Owner represented as a real Page. Owner could be also just a Dataobject instead.
Especially if you want to output just JSON in the end you are maybe completely independent of Sitetree/Pages... then you could write a custom controller with a routing rule and which gives you back just the data that you need:
http://doc.silverstripe.org/framework/en/topics/controller
regards,
Florian
I am looking for guidance regarding the best practice around the use of the Profile feature in ASP.NET.
How do you decide what should be kept in the built-in user Profile, or if you should create your own database table and add a column for the desired fields? For example, a user has a zip code, should I save the zip code in my own table, or should I add it to the web.config xml profile and access it via the user profile ASP.NET mechanism?
The pros/cons I can think of right now are that since I don't know the profile very well (it is a bit of a Matrix right now), I probably can do whatever I want if I go the table route (e.g., SQL to get all the users in the same zip code as the current user). I don't know if I can do the same if I use the ASP.NET profile.
Ive only built 2 applications that used the profile provider. Since then I have stayed away from using it. For both of the apps I used it to store information about the user such as their company name, address and phone number.
This worked fine until our client wanted to be able to find a user by one of these fields.
Searching involved looping through every users profile and comparing the information to the search criteria. As the user base grew the search time became unacceptable to our client. The only solution was to create a table to store the users information. Search speed was increased immensely.
I would recommend storing this type of information in its own table.
user profile is a nice clean framework for individual customization(AKA. Profile Properties). (e.g. iGoogle)
the problem of it is its not designed for query and not ideal for data sharing to public user.(you still would be able to do it, with low performance)
so, if you want to enhance the customized user experience, user profile would be a good way to go. otherwise, use your own class and table would be a much better solution.
In my experience its best to keep an the info in the profile to a bare minimum, only put the essentials in there that are directly needed for authentication. Other information such as addresses should be saved in your own database by your own application logic, this approach is more extensible and maintainable.
I think that depends on how many fields you need. To my knowledge, Profiles are essentially a long string that gets split at the given field sizes, which means that they do not scale very well if you have many fields and users.
On the other hand, they are built in, so it's an easy and standardized way, which means there is not a big learning curve and you can use it in future apps as well without needing to tweak it to a new table structure.
Rolling your own thing allows you to put it in a properly normalized database, which drastically improves performance, but you have to write pretty much all the profile managing code yourself.
Edit: Also, Profiles are not cached, so every access to a profile goes to the database first (it's then cached for that request, but the next request will get it from the database again)
If you're thinking about writing your own thing, maybe a custom Profile Provider gives you the best of both worlds - seamless integration, yet the custom stuff you want to do.
I think it is better off using it for supplementary data that is not critical to the user that is only normally important when that user is logging in anyway. Think data that would not break anything important if it was all wiped.
of course thats personal preference but others have raised some other important issues.
Also very useful considering it can be used for an unauthenticated user whose profile is maintained with an anonymous cookie.