throwing "Document name does not match class name" - if production minified js is used

[aaronthorp]

(Using version 0.6.0 of peer-db with Meteor 0.8.0)

lib.coffee:438

---
throw new Error "Document name does not match class name" if @name and @name isnt meta.name

Receiving this error for:

class @User extends Document
  @Meta
    name: 'User'
    collection: Meteor.users

when running meteor --prodcution because the class gets minified to n instead of User etc.

[mitar]

Huh, good catch. What would be here a good solution. Don't require matching? Don't require it only in production? Is there a way for code to signal that some symbol should not be minimized.

[aaronthorp]

I was searching around for a way to not minimize the symbols, but haven't been able to find anything thus far.

Having said that, probably not checking it if it is in production mode would work as theoretically the testing and debugging should have been done in debug mode and then production mode should just work and not really matter what it is called.

Would it need to keep a list of class names vs. the Meta names in the store so that it could interperet what class the n equated to for example?

[mitar]

I think it should work if we disable checking in the production. I am just not sure how to detect that we are running in the production mode.

[aaronthorp]

Not sure on that one either, I rolled back until I could get it to work, seems 0.3.8 is the latest I can get working with production mode, just before the "name" variable in the meta, but for some reason peerdb makes the app take ~5 minutes to start in production mode where its pretty quick in debug :(

I forked and attempted a few little hacks on the throw and the naming detection but no luck so far...

[mitar]

Interesting, in 0.3.8 I had code which in production mode recomputed all references (to make sure everything is consistent when a node starts): https://github.com/peerlibrary/meteor-peerdb/blob/952d877e6ef615f9d8fe5ac57969d35e506233af/server.coffee#L368

I later on removed this and made a function so that you can decide for yourself if you want or not want to run it and when.

But this is interesting. You are saying that my test for production mode works for you? Because it should not. :-)

[mitar]

(The rationale was that you will not restart a node in the production mode often, so long booting time is good because you have data consistency for that.)

[mitar]

Fixed and released a new version.