Is "LEFT_SUBFIELD only supports Object" Error on Nulls Really Necessary?
1,023 views
Skip to first unread message
Caleb Jones
Feb 28, 2012, 10:34:18 AM2/28/12
to mongodb-user
Repro:
> db.testing.insert({"data":null})
> db.testing.update({"data":null}, {"$set": {"data.id" : 1}})
LEFT_SUBFIELD only supports Object: data not: 10
I understand why this is the case, it's like a null pointer exception
since you're trying to access a field in a subdoc when that subdoc
doesn't exist or is null.
My question is how difficult would it be for the server core to handle
this more gracefully and automatically create a subdoc *IFF* the
parent field ("data" in the example) is null? Would a new operator
other than $set or a modifier parameter on $set be necessary to do
this? Note the *IFF* is important since you wouldn't want to replace a
non-null primitive with a document and possibly loose data.
What'd be nice is if it behaved this way:
> db.testing.insert({"data":null})
> db.testing.update({"data":null}, {"$set": {"data.id" : 1}})
> db.testing.find({"data.id":1})
{ "_id" : ObjectId("4f4cf14e46c4db0e7a4b12d8"), "data" : { "id" :
1 } }
> db.testing.insert({"data":"foo"})
> db.testing.update({"data":"foo"},{"$set": {"data.name":"foo"}})
LEFT_SUBFIELD only supports Object: data not: 2
Thoughts?
> db.testing.insert({"data":null})
> db.testing.update({"data":null}, {"$set": {"data.id" : 1}})
LEFT_SUBFIELD only supports Object: data not: 10
I understand why this is the case, it's like a null pointer exception
since you're trying to access a field in a subdoc when that subdoc
doesn't exist or is null.
My question is how difficult would it be for the server core to handle
this more gracefully and automatically create a subdoc *IFF* the
parent field ("data" in the example) is null? Would a new operator
other than $set or a modifier parameter on $set be necessary to do
this? Note the *IFF* is important since you wouldn't want to replace a
non-null primitive with a document and possibly loose data.
What'd be nice is if it behaved this way:
> db.testing.insert({"data":null})
> db.testing.update({"data":null}, {"$set": {"data.id" : 1}})
> db.testing.find({"data.id":1})
{ "_id" : ObjectId("4f4cf14e46c4db0e7a4b12d8"), "data" : { "id" :
1 } }
> db.testing.insert({"data":"foo"})
> db.testing.update({"data":"foo"},{"$set": {"data.name":"foo"}})
LEFT_SUBFIELD only supports Object: data not: 2
Thoughts?
Adam C
Feb 29, 2012, 11:52:12 AM2/29/12
to mongod...@googlegroups.com
This seems like a logical progression, essentially allowing upserts for the null data type as well as a non-existent field (which is the current behavior). There may be complexity involved in actually implementing this of course, so providing a use case that makes sense would help push it along (and get votes) if this is a non-trivial implementation.
Feel free to file this as a feature request in the SERVER project where the complexity can be fully evaluated.
Adam.
Adam.
Randolph Tan
Feb 29, 2012, 11:54:47 AM2/29/12
to mongod...@googlegroups.com
Hi,
Would this update work for you?
db.testing.update({ data: null }, { $set: { data: { id: 1 }}});
Caleb Jones
Feb 29, 2012, 12:49:47 PM2/29/12
to mongodb-user
Yes this will work technically. But the context in which I'm hitting
this error is such that I don't know (and don't want to know) whether
"data" is null or not and want to be able to easily transition between
the two.
this error is such that I don't know (and don't want to know) whether
"data" is null or not and want to be able to easily transition between
the two.
Caleb Jones
Feb 29, 2012, 1:01:56 PM2/29/12
to mongodb-user
The use case I have is I'm providing a uniform way to programmatically
do updates and trying to avoid forcing document introspection prior to
update for this scenario.
Another, more common, use case that comes to mind is data migration.
You may want to move/copy fields into a subdoc. This would be simple
if dot notation automatically created the necessary subdoc(s) in order
to match the intent of the notation (kind of like mkdirs or mkdir -p).
Again, I would prefer that there *IS* an error if the type is a non-
null primitive (e.g. number, string, etc.).
do updates and trying to avoid forcing document introspection prior to
update for this scenario.
Another, more common, use case that comes to mind is data migration.
You may want to move/copy fields into a subdoc. This would be simple
if dot notation automatically created the necessary subdoc(s) in order
to match the intent of the notation (kind of like mkdirs or mkdir -p).
Again, I would prefer that there *IS* an error if the type is a non-
null primitive (e.g. number, string, etc.).
Caleb Jones
Feb 29, 2012, 2:30:27 PM2/29/12
to mongodb-user
Reply all
Reply to author
Forward
0 new messages