I'm wanting to create an admin dashboard for my app, and to show new events there. In order to know which events are new, I'll need to store at least one extra datapoint to the server: the last date at which the admin user (me) looked at the events and marked them all as read.

I'm trying to figure out where it makes sense to store that data.

I'm using Mongoose, and have a few different document types. Options I've considered include:

  • create an extra field on the user schema, that will be undefined for all non-admin users
  • create a new document type just to store admin data
  • use mongodb directly, rather than going through mongoose

Is one of these better than the others? Have I missed something that's obviously better than all of them?


I'm not familiar with Mongoose but we have started pushing configuration out of xml files and into the DB using ravendb. Our approach is to:

  • We create a configuration object or object graph with sensible defaults.
  • We write a configuration manager class that provides:
    • automatic creation of the object if it does not exist
    • singleton access to the class
    • manages caching, etc if required

On the database level it is just a special document with a fixed ID -- hence the singleton. We have had a few approaches where we could swap various configurations into the "active" singleton as well. From the code's perspective little has changed -- we typically injected configuration using IoC containers so the codebase has been pretty agnostic. Config is just manna from heaven.

Overall I'm pretty happy with it. The biggest downside is it takes config out of version control which is a feature I've really liked for the auditability aspect.

  • Yeah, this is approximately what I've done. Things are still small-scale, so I just load the DB object into memory when the app starts up, and modify and save it as necessary. Nov 12 '14 at 18:47

I have something similar in my app. If the admins are not too many, I have an array updatedUsers[] in each event document that contains the names of the people that have seen the event. If the user's name isn't in it then it's new for him. If you are going to query for new though, then you may need to reverse this (so you keep the notUpdatedUsers[] and query mongo for the username in this field, indexed of course). mongoose or not is your choice.


The second option is way better.

Applying an ORM sort of architecture would be awesome.

The user's schema should probably have an extra field named account_type which will be mapped to account schema which contains list of all type of users on your application. Or you can have an extra string field called authorities, so for a normal user will have the ROLE_USER and probably ROLE_ADMIN for the admin user.

A different schema should hold your event data with an extra field in it named status which could hold the value "READ" or "UNREAD" depending on which works for you.


I'm not familiar with mongoose specifically, but I note that your first suggestion has an interesting problem: if you later expand the number of admin users, you will have multiple copies of the data that do not necessarily agree with each other, whereas it seems that for your application you truly do want the data to be global (as multiple admin users shouldn't have to all review the same events). This points strongly toward your second option.

As I'm unfamiliar with mongoose, I don't know if there is any reason talking directly to mongodb would be beneficial to you, but if the second option is a possibility I see no reason it should be necessary.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.