I'm just changing my project from the old 2.13 to the new 3.3 java driver. Now given that Document is going to replace DBObject anyway, I thought I'd replace it. Everything works like a charm ... except that the (old) DB isn't accepting the documents I try to throw at it.
Shouldn't insertOne accept the org.bson.Document just fine as it was taking DBObject before?
My Documents are built like this:
static synchronized Document CommentsToDocument(Comment comment) {
return new Document().append("source", comment.getSource()).append("date", comment.getDateTime())
.append("author", comment.getAuthor()).append("thread", comment.getThreadID())
.append("commentID", comment.getCommentID()).append("title", comment.getTitle())
.append("comment", comment.getComment());
}
static synchronized Document UrlsToDocument(String url, int counter) {
return new Document("url", url).append("count", counter);
}
Those Documents are then added to a deque. And should be inserted like this:
static synchronized void writeToDb(String col, ConcurrentLinkedDeque<Document> comments) {
MongoCollection<Document> collection = database.getCollection(col);
for (Document o : comments) {
collection.insertOne(o);
}
}
Yes I know, the writeToDb is rather inelegant, and I'll work out a better way. ;)
For now I only face the problem, that the DB that accepted BasiDBObjects of the same composition just fine is not accepting the Documents.
Are the Objects stored as BasicDBObjects internally so that I have to parse the Documents first? Or is there a way to get the DB to accept the Documents as they are, with the DB parsing them internally?
Or do I have to read all the Objects from the old DB, create a new one, and write them back after reparsing? o.O
Thank you for your advice.
PS: I've read through the CRUD Operations info already, but couldn't find any reason why it wouldn't accept my Document Objects just fine. I'm probably to inexperienced to see the obvious, so yeah. ;)
PPS: Interestingly I can read Documents just fine. The only difference between the documents I get out and try to get in, is the lack of _id ... which shouldn't be a problem. I've also looked into the possibility of an index problem, but the url collection is only uniquely indexed over the url (and the _id of course) and should accept new (differing) entries.
Found the solution. Apparently some bool flag on a completely different part of the code got reset. Your questions on the exceptions lead me on the right path, as there were NON. Which meant it was no DB problem at all. The DB correctly shrugged of all documents it already had in its index.