I've noticed this funny thing when instantiating the model in mongoose - the instance can be changed through other means than instance itself. Here's an example:
var articleSchema = new Schema({
name: 'String',
price: 'Number'
});
var Article = mongoose.model('Article', articleSchema);
var nexus = new Article({
name: 'Nexus 5',
price: 300
});
nexus.save(function(err, instance) {
instance.name = 'Nexus Five';
instance.save(function(err, instance2) {
instance2.name = 'Nexus 5ive';
instance2.save(function(err, instance3) {
console.log(nexus.name); //'Nexus 5ive'
});
});
});
As you can see in the example I never changed the name property of nexus, I changed the properties of the model that save function returned in the callback. Is it OK to approach changing the data in this way? Or should I just stick to the firstly defined instance (i.e. nexus variable)? It seems a bit confusing, since you can easily lose control on what you're dealing with.
The save function returns a model. If you wish you can continue modifying it.
But as the model instance you get back will always be exactly the same as the one you saved, I can't imagine when it would be truly useful not to to just keep mutating the original model. By the same token when would you ever mutate the original document, save it, mutate it again, then save it again? I'm not coming up with any scenarios where I would write the code in your example.
If you call findOneAndUpdate with the new option, suddenly the returned model instance becomes useful, since it's a fresh copy of the document (one which might have been mutated by another client).
Related
I am reading in several places that I should be able to get the data context of the current template with Template.currentData();
I found that it seems to only work within an autorun. But after logging the data as a variable there, first it logs null, then it logs the data in the console.
When I try to use the data, like for example trying to pass data._id into a subscription, I get a TypeError in the console. TypeError: Cannot read property '_id' of null. So for some reason, the data is null and I am struggling to find out why.
I have the data context set within my routes using Iron Router:
Router.route('/stock/:stockNumber', {
name: 'stock.detail',
template: 'StockDetail',
data: function () {
return Stock.findOne({
stockNumber: this.params.stockNumber*1
});
}
});
What I am trying to do is get access to the data context so that I can pass some things from it, such as the '_id' into some other subscriptions. What am I doing wrong?
The template is otherwise correctly displaying the data on the page as expected, and I can use Spacebars to show things like {{_id}} for example. But again, I seem to be unable to get access to the data context in Template.StockDetail.onCreated
Ok, so here's what I ended up doing...
Apparently the data context is just simply not available in the onCreated, period. What I had to do was do a Collection.findOne() within the autorun to find the stockItem and set the result to a variable, then use the stockItem._id as the parameter in the new subscription IF the item was found. With both of these things, it seems to work just fine.
Template.StockDetail.onCreated(function () {
let instance = this;
instance.autorun(function () {
instance.subscribe('stock_item', Router.current().params.stockNumber);
let stockItem = Stock.findOne({ // This is what was needed for some reason...
stockNumber: Router.current().params.stockNumber*1
});
if (stockItem) { // ...and, also, this was needed
instance.subscribe('stock_item_scan_log', stockItem._id);
}
});
});
I just don't understand why I can't just easily get the _id some other way. This way just feels incorrect and I don't like it.
I have a problem with some dynamically generated forms and passing values to them. I feel like someone must have solved this, or I’m missing something obvious, but I can't find any mention of it.
So for example, I have three components, a parent, a child, and then a child of that child. For names, I’ll go with, formComponent, questionComponent, textBoxComponent. Both of the children are using changeDetection.OnPush.
So form component passes some values down to questionComponent through the inputs, and some are using the async pipe to subscribe to their respective values in the store.
QuestionComponent dynamically creates different components, then places them on the page if they match (so many types of components, but each questionComponent only handles on one component.
some code:
#Input() normalValue
#Input() asyncPipedValue
#ViewChild('questionRef', {read: ViewContainerRef}) public questionRef: any;
private textBoxComponent: ComponentFactory<TextBoxComponent>;
ngOnInit() {
let component =
this.questionRef.createComponent(this.checkboxComponent);
component.instance.normalValue = this.normalValue;
component.instance. asyncPipedValue = this. asyncPipedValue;
}
This works fine for all instances of normalValues, but not for asyncValues. I can confirm in questionComponent’s ngOnChanges that the value is being updated, but that value is not passed to textBoxComponent.
What I basically need is the async pipe, but not for templates. I’ve tried multiple solutions to different ways to pass asyncValues, I’ve tried detecting when asyncPipeValue changes, and triggering changeDetectionRef.markForChanges() on the textBoxComponent, but that only works when I change the changeDetectionStrategy to normal, which kinda defeats the performance gains I get from using ngrx.
This seems like too big of an oversight to not already have a solution, so I’m assuming it’s just me not thinking of something. Any thoughts?
I do something similar, whereby I have forms populated from data coming from my Ngrx Store. My forms aren't dynamic so I'm not 100% sure if this will also work for you.
Define your input with just a setter, then call patchValue(), or setValue() on your form/ form control. Your root component stays the same, passing the data into your next component with the async pipe.
#Input() set asyncPipedValue(data) {
if (data) {
this.textBoxComponent.patchValue(data);
}
}
patchValue() is on the AbstractControl class. If you don't have access to that from your question component, your TextBoxComponent could expose a similar method, that can be called from your QuestionComponent, with the implementation performing the update of the control.
One thing to watch out for though, if you're also subscribing to valueChanges on your form/control, you may want to set the second parameter so the valueChanges event doesn't fire immediately.
this.textBoxComponent.patchValue(data, { emitEvent: false });
or
this.textBoxComponent.setValue(...same as above);
Then in your TextBoxComponent
this.myTextBox.valueChanges
.debounceTime(a couple of seconds maybe)
.distinctUntilChanged()
.map(changes => {
this.store.dispatch(changes);
})
.subscribe();
This approach is working pretty well, and removes the need to have save/update buttons everywhere.
I believe I have figured out a solution (with some help from the gitter.com/angular channel).
Since the values are coming in to the questionComponent can change, and trigger it's ngOnChanges to fire, whenever there is an event in ngOnChanges, it needs to parse through the event, and bind and changes to the dynamic child component.
ngOnChanges(event) {
if (this.component) {
_.forEach(event, (value, key) => {
if (value && value.currentValue) {
this.component.instance[key] = value.currentValue;
}
});
}
}
This is all in questionComponent, it resets the components instance variables if they have changed. The biggest problem with this so far, is that the child's ngOnChanges doesn't fire, so this isn't a full solution. I'll continue to dig into it.
Here are my thoughts on the question, taking into account limited code snippet.
First, provided example doesn't seem to have anything to do with ngrx. In this case, it is expected that ngOnInit runs only once and at that time this.asyncPipedValue value is undefined. Consequently, if changeDetection of this.checkboxComponent is ChangeDetection.OnPush the value won't get updated. I recommend reading one excellent article about change detection and passing async inputs. That article also contains other not less great resources on change detection. In addition, it seems that the same inputs are passed twice through the component tree which is not a good solution from my point of view.
Second, another approach would be to use ngrx and then you don't need to pass any async inputs at all. Especially, this way is good if two components do not have the parent-child relationship in the component tree. In this case, one component dispatches action to put data to Store and another component subscribes to that data from Store.
export class DataDispatcherCmp {
constructor(private store: Store<ApplicationState>) {
}
onNewData(data: SomeData) {
this.store.dispatch(new SetNewDataAction(data));
}
}
export class DataConsumerCmp implements OnInit {
newData$: Observable<SomeData>;
constructor(private store: Store<ApplicationState>) {
}
ngOnInit() {
this.newData$ = this.store.select('someData');
}
}
Hope this helps or gives some clues at least.
There is a method named updateBindings(true?) in openui5. But I'm not sure when I have to invoke it. Sometimes, setting the modified data to a model causes view changes, which indicates the underlying model data actually gets changed. Sometimes it won't work.
The first example demonstrates that the model doesn't get changed without updateBindings(true).
http://jsbin.com/hulavutoha/edit?html,css,output
The second example derives from the first one. But the model gets updated even without updateBindings(true).
http://jsbin.com/lepuladivu/edit?html,css,output
So, what's the difference between the two examples? When do I need to invoke updateBindings(true) on a model so that it will get updated? What's the intent of the parameter true passed to updateBindings()?
If you add a console print in your formatter function
formatter : function(books) {
console.log("go!!!");
return books[0];
}
you can see that in the first example the function is not executed.
This because if you change a leaf property the linked conponent in thew view (using data-binding) receive the change event only if it bind exactly the leaf property.
P.S.
Instead to use getData
var data = oModel.getData();
data.books[0] = "my book";
oModel.setData(data);
you can use getProperty
var data = oModel.getProperty("/");
data.books[0] = "my book";
//oModel.setProperty("/", data);
In this mode the last line is not required
I'm a couple hours new to Meteor and Mongo, coming from a Rails background and trying to understand how migrations work - or don't maybe?
I have a server/bootstrap.js file that I use to seed some data:
// if the database is empty on server start, create some sample data.
Meteor.startup(function () {
if (Users.find().count() === 0) {
var userData = [
{ name: 'Cool guy' },
{ name: 'Other dude' }
];
for (var i = 0; userData.length; i++) {
var userId = Users.insert({
name: userData[i].name
});
}
}
});
It seems like every time I want to change the database, say to add a new field, I have to run meteor reset to get it to pick up the changes.
But what happens if I create records or other data through the UI that I want to keep? In Rails, working with MySQL or PostgreSQL, I'd create a migration to create new fields without blowing away the entire database.
How does this work with Meteor and Mongo? Also thinking of the case of rolling out new changes from development to production. Thanks!
-- Update: 2013/09/24 --
Apparently, the schema-less nature of Mongo reduces or eliminates the need for migrations. In my case, modifying userData to add new fields won't work after it runs initially because of the Users count check - which is why I kept running meteor reset. I'll need to rethink my approach here and study up.
That said, there are projects out there that use migrations, like Telescope: https://github.com/SachaG/Telescope/blob/master/server/migrations.js
I also found the tutorial at http://try.mongodb.org/ useful.
First of all, your code is perfectly valid. And you know that.
mrt reset gives you a 'fresh' - empty database (as mentionned already).
If you want to reset a particular collection, you can do it so :
MyCollection.remove({});
But you have to understand the nature of NoSQL : there are no constraints on the data. It could be called NoREL (as in not a relational database, source : Wikipedia ).
MongoDB is also schema-less.
This means that you can use any field you want in your data. This is up to you (the programmer) to enforce specific constraints if you want some. In other words, there is no logic on the mongo side. It should accept any data you throw at it, just like Hubert OG demonstrated. Your code snippet could be :
// if the database is empty on server start, create some sample data.
Meteor.startup(function () {
if (Users.find().count() === 0) {
var userData = [
{ name: 'Cool guy' },
{ name: 'Other dude' },
{ nickname: 'Yet another dude' } // this line shows that mongo takes what you throw him
];
for (var i = 0; userData.length; i++) {
var userId = Users.insert({
name: userData[i].name
});
}
}
});
Source : http://www.mongodb.com/nosql
There is no need for migration there. You only have to add the logic in your application code.
Note : To import/export a database, you can have a look there : mongo import/export doc, and maybe at the db.copyDatabase(origin, destination, hostname) function.
There are no migrations in Mongo — there is no scheme! If you want to add a new field that was not there before, just do it and it will work. You can even have completely different documents in the same collection!
Items.insert({name: "keyboard", type: "input", interface: "usb"});
Items.insert({cherries: true, count: 5, unit: "buckets", taste: "awesome"});
This will just work. One of main reasons to use NoSQL (and advantages of Meteor over Rails) is that you don't have migrations to worry about.
Using mrt reset to change db model is a terrible idea. What it actually does is complete reset of db — it removes all of your data! While it's sometimes usefull in development, I bet it's not what you want in this case.
I'm doing the following using Mongoose:
that.model.update({_id: dao._id}, dao, { upsert: true }, cb);
Where dao is a mongoose representation containing (among other things) a couple of embedded documents. As a test I've deleted a couple of the embedded docs from the array before calling the update-method above.
The result is that the change to the array of embedded docs IS NOT persisted.
Anything I'm overlooking?
Hard to be certain w/o seeing more code, but if dao is a Mongoose model instance, you should be calling dao.save(cb); instead.
I solved the problem by doing something similar as proposed in the following issue: https://github.com/LearnBoost/mongoose/issues/571
For completeness some background which led to the problem.
I'm using DDD repositories which are populated on app-start. Under the hood this fetches Mongoose-objects (which are treate as DAOs in my situation) and are translated to domainobjects, which are cached in the repository. I need this separation between domainobjects and mongoose-objects, don't ask.
This means that getById, getAll and all other public interfaces of the repo work with domainobjects and not with mongoose-objects.
When doing things like add or update on the repo this internally only updates the in-mem cache (which, again, only uses domainobjects instead of mongoose-objects)
Only when doing commit on the repo does the possibly changed collection of domainobjects get persisted. This is done by creating NEW Mongoose-objects instead of fetching Existing mongoose-objects and updating those.
This is why I can't use dao.save() since, when I'm saving a different (just created) mongoose-object while a mongoose-object with the same id may possibly already exist in Mongo, it throws a duplicate id error.
Some relevant snippet from by code illustrating the solution:
var dao = that.createDAO(domainobject);
//https://github.com/LearnBoost/mongoose/issues/571
// Convert the Model instance to a simple object using Model's 'toObject' function
// to prevent weirdness like infinite looping...
var upsertData = dao.toObject();
// Delete the _id property, otherwise Mongo will return a "Mod on _id not allowed" error
delete upsertData._id;
that.model.update({_id: dao._id}, upsertData, { upsert: true }, cb);