Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Track loaded keys at the instance level #195

Open
jnunemaker opened this Issue · 4 comments

3 participants

@jnunemaker
Owner

http://groups.google.com/group/mongomapper/browse_thread/thread/d0f698407ff12ae

Only show loaded keys when inspecting. If key is requested that has not been loaded, maybe we should perform query for it? This would make it so that identity map could keep track of models with partially loaded keys as well instead of ignoring them.

Also along these lines we should not add dynamic keys to the class, but instead just to the instance.

@JonKernPA

I can see it both ways... I also posted about this: http://technicaldebt.com/?p=952

If the key was a mistake, remove it.

If the key was added for an instance or three... but it is not in the class, should it be revealed or hidden?

I can see MongoDB opting for the default to show the superset. It would be maddening to know you added some documents with certain keys, only to not ever be able to find them! Also, this allows you to be much more dynamic about storing new key/value pairs on the fly and being able to always know what keys are available. (More akin to RDF "loose" data schemas.)

I can also see wanting to know only what is in the "official" class model.

So, I don't think it is an either / or thing.

@cheald
Owner

I'm working on a changeset right now that addresses both of these issues.

  1. Loaded keys are tracked. Right now, they're only limited in inspection, but it would be easy enough to make the ODM query for missing variables and fill in the blanks when requested.
  2. Keys that aren't defined on the model aren't extended into the class permanently. This has exposed a couple of bugs in embedded documents that only worked because of certain execution orders in the test suite and ensures that the model is only what the programmer has explicitly defined it to be. This means that you couldn't have loaded key tracking "fill in the blanks" when you request a key that isn't defined on the document, but that's fine, IMO - if you want to use a field as a model attribute, you should be declaring it as a model attribute. As a bonus, this will pave the way for a "strict" mode that disallows the creation of non-declared fields, which is an open feature request.
@cheald
Owner

Okay, so after spending an afternoon on it, I'm thinking the following:

  • We should provide a strict mode that prevents keys from being implicitly created. This is trivial to do with loaded key tracking.
  • Not creating permanent class keys means a rather dramatic performance loss when you have a key that is consistently in documents loaded by the model. To this end, I think that we should probably have a couple of modes here:
    • implicit_schema(bool = true) - allow for automatic creation of keys on model classes (that is, let the schema be implicitly defined)
    • strict_keys(bool = false) - when true, would raise an exception upon encountering a key that isn't defined on the model.

The implicit_schema(true) and strict_keys(false) defaults would behave the same way that documents currently behave today - keys are aggregated on the class, and undefined keys are handled automatically.

Setting implicit_schema(false) would move key creation for unknown fields from the class to the instance. This means that a given instance would have accessors for the unknown keys, but that they wouldn't become a permanent part of the model schema.

Setting strict(true) would raise an exception upon attempting to handle an attribute that is not defined on the model.

This could use some alternate interface, like schema(:strict => <bool>, :implicit => <bool>) for more condensed application.

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.