3

Here is the situation:

There is a Mongo database A and there is Mongo database B.

There is a business concept/Mongo object that is called someModel which exists on one of database B's collections.

Here is the question. The way we generate this someModel is based on other object's data from database A. And there are times when we want to load all of the existing someModels (actually existing objects in database B) and non-existing ones which are just a conglomerate of data from database A's collections (as mentioned).

Now for the existing someModeles we have a Mongo id which is unique and has been generated at the time of creation, however for non-existing someModels we don't have an id yet. The reason we need it is for identification/matching purposes (between front end and back end).

Bottom line is that I am thinking of generating an ID through Mongoose and have a fully populated DTO at all times even if the ID is going to be temporary (until it is saved) and only used for identification/matching purposes - however once saved the "temporary id" will now become permanent.

I purposefully made it very abstract so that it sounds like a general problem instead of making it business specific but if you guys need more details please ask and I will surely provide them.

So that's the question - if generating ids for a non-existing object in the database is bad practice in this specific context.

Thank you guys and appreciate your time and support!

Improve this question
6
  • Do I understand correctly that this temporary ID is generated by the DB is never used in the DB? If so, what is the benefit of generating it in the DB?
    – JimmyJames
    Commented Nov 9, 2016 at 17:32
  • @JimmyJames hmm I don't think that's what I meant. Basically, the BSON object _id is automatically generated by Mongo on object creation and it is used in the database to identify uniqueness of the objects (by default), outside of the db it is used to do matching on front-end/back-end. Hope that clarified it, if not let me know and I will try to change up the question a bit. Thanks!
    – SurrealSyntax
    Commented Nov 9, 2016 at 17:37
  • "going to be temporary and only used for identification/matching purposes - and on save a new one gets generated." The part I'm trying to understand is the last part after the '-'.
    – JimmyJames
    Commented Nov 9, 2016 at 19:40
  • Apologize for a very late reply @JimmyJames. Scratch that part because I didn't explain myself correctly. I meant to say - if one just loads the page the ids for the non-existing ones will be generated and if the page is refreshed they will be regenerated. However, the moment we save them to the database the ids get locked into place as in the same generated id will now get saved. I will also updated my question and thank you for pointing that out!
    – SurrealSyntax
    Commented Nov 10, 2016 at 15:26
  • 1
    OK. At a high-level this is completely fine. The only concern I would have is running out of available ids as explained in the accepted answer. For example, a 32-bit int holds a pretty big number but it's easy to overflow it. Pick something that is bigger than you'll ever possibly need.
    – JimmyJames
    Commented Nov 10, 2016 at 15:41

2 Answers 2

Reset to default
3

As often, it depends. Since you asked for a general answer, I am trying to give one independent from the specific technology, here MongoDB.

If the allowed domain range for the IDs is huge, and you are not letting your database generate several millions of IDs per second, so the risk of running out of available IDs in a reasonable amount of time is small, then you can take those IDs and use them for whatever you want (even if that means you use them only temporarily and then throw them away).

On the other hand, when the above preconditions are not fulfilled, you need to be careful not to come to a point where you run out of IDs or get ID collisions.

For example, using GUIDs as IDs (which use a domain range of 128 bit numbers) makes it very unlikely to get ID collisions as long as you do not create a huge amount of them in a short time, especially when you can restrict the collision tests for your special use case.

Also be careful that domain ranges which look huge today might not look so huge tomorrow (best example is the IP V4 protocol, where the available adresses have become scarce over the years).

Improve this answer
4
  • Which is why IPv6 has an address space that is many orders of magnitude larger.
    – Robert Harvey
    Commented Nov 9, 2016 at 17:06
  • Mongodb ObjectIDs get generated without accessing the database, similar to GUIDs. (though the algorithm is a bit risky for my taste)
    – CodesInChaos
    Commented Nov 9, 2016 at 17:12
  • @CodesInChaos: yep, looked just into the docs, seems to be a 12 byte number. Nevertheless the OP needs to check how he does the ID generation and how likely it is that he gets collisions in his use case.
    – Doc Brown
    Commented Nov 9, 2016 at 17:17
  • Thank you @DocBrown for your answer. There won't be a scenario where I am generating that many, also for the id I am thinking of getting current date (time included in milliseconds) and use that string value to generate a new BSON object id through Mangoose. That should guarantee it to be virtually unique right?
    – SurrealSyntax
    Commented Nov 9, 2016 at 17:27
0

Actually you are not "generating ids for a non-existing object in the database [B]". This object exists.

@AvetisG, you have someModel entity and someModel entity attributes separated. Application logic is a master of someModel entities, A and B are each a master of some of someModel entity attributes. In your context it is quite valid to have a unique someModel entity (with its ID) in master (logic), but not have its attributes in A and/or B yet.

I'm not sure if it has a meaning in your specific situation, but for me it seems to be no reason to keep ID (link to someModel entity) in B and do not keep it in A. Consider an option to generate IDs (create someModel entities) for all of those "just conglomerates of data" which are absent in B and store them. It would make someModel entity lifecycle more obvious form data perspective. (Running with settings storages without entity storage is also a question.)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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