I have a datasource in manual save mode. When I create the item and persist the changes, I get an error message, saying Id field is null. Id field is the primary key and hence cannot be assigned through front end. Any ideas why AppMaker thinks it is missing.
Code is this
widget.datasource.createItem({
success: function(){
app.datasources.CountyManualSave.saveChanges({
success: function() {console.log('yey');},
failure: function(e) {showSnackbar(e.message);}
});
},
failure: function(e) {showSnackbar(e.message);}
});
Here's the image, that shows it is the primary key. Doing the insert through the Mysql client works without problems.
I am not sure what was wrong but I unclicked the auto increment and reclicked the auto increment under field Id. Previewed again. Things worked. I am leaving this question here in case somebody questions their sanity. This is to show that environment is not always stable.
Related
I am using "meteor.loginWithPassword" in my website for logging in but in the matter of fact I always get the error : "Match failed".
I do not find the reason why?
I have the user I am testing in my Database. I read somewhere that it is because one of the fields are empty, but this is not the reason.
I don`t know what should I check?
Template.login.events({
'submit form': function(event){
event.preventDefault();
var username = $('[name=username]').val();
var password = $('[name=password]').val();
Meteor.loginWithPassword(username, password, function(error){
console.log(error);
});
}
});
How to understand the error
When you're getting a Match error that's ultimately from the 'meteor/check' library.
So what you want to solve is "what Match conditions does the Meteor.loginWithPassword method expect". This will tell you what argument values will be permitted at runtime.
To answer that question you can look here https://github.com/meteor/meteor/blob/devel/packages/accounts-password where the code that sets up that method is defined.
NOTE: code references from here on arbitrarily reference version 2.5.8 to keep line references. However you could search under the version your code is at in essentially the same place
More specifically you're interested in the check call here https://github.com/meteor/meteor/blob/release/METEOR%402.5.8/packages/accounts-password/password_server.js#L170,#L173.
Bonus Round
It's worth noting that even if you were crawling the source code and found where Meteor.loginWithPassword is defined here https://github.com/meteor/meteor/blob/release/METEOR%402.5.8/packages/accounts-password/password_client.js#L33 it wouldn't be super obvious that the method call there gets picked up by the handler here https://github.com/meteor/meteor/blob/release/METEOR%402.5.8/packages/accounts-password/password_server.js#L166.
As it turns out the handlers match on the shape of arguments not the name 🙃.
I am new to firebase and I am having a bit of a nightmare trying to adapt old code to what is now deprecated and what is not. I am trying to write a function which updates one "single" record in my datasource using the now approved $save()promise but it is doing some really strange stuff to my data source.
My function (should) enables you to modify a single record then update the posts json array. However, instead of doing this, it deletes the whole datasource on the firebase server and it is lucky that I am only working with testdata at this point because everything would be gone.
$scope.update = function() {
var fb = new Firebase("https://mysource.firebaseio.com/Articles/" + $scope.postToUpdate.$id);
var article = $firebaseObject(ref);
article.$save({
Title: $scope.postToUpdate.Title,
Body: $scope.postToUpdate.Body
}).then(function(ref) {
$('#editModal').modal('hide');
console.log($scope.postToUpdate);
}, function(error) {
console.log("Error:", error);
});
}
Funnily enough I then get a warning in the console "after" I click the button:
Storing data using array indices in Firebase can result in unexpected behavior. See https://www.firebase.com/docs/web/guide/understanding-data.html#section-arrays-in-firebase for more information. Also note that you probably wanted $firebaseArray and not $firebaseObject.
(No shit?) I am assuming here that $save() is not the right call, so what is the equivalent of $routeParams/$firebase $update()to do a simple binding of the modified data and my source? I have been spending hours on this and really don't know what is the right solution.
Unless there's additional code that you've left out, your article $firebaseObject should most likely use the fb variable you created just before it.
var article = $firebaseObject(fb);
Additionally, the way in which you're using $save() is incorrect. You need to modify the properties on the $firebaseObject directly and then call $save() with no arguments. See the docs for more.
article.Title = $scope.postToUpdate.Title;
article.Body = $scope.postToUpdate.Body;
article.$save().then(...
I am using Meteor 0.8.2 with accounts-facebook. I set up a limited publication for the users this way:
Meteor.publish('users', function () {
return Meteor.users.find({}, {fields: {'profile.picture': 1, 'profile.gender':1, 'profile.type':1}, sort: {'profile.likes': -1}});
});
Now this works great: when I requests a user list from the client I get a list of all users, with the current user's fields all shown and only the 3 published fields for the others. Except: right after login.
When I login and type Meteor.user(), here is what I get:
_id: "uACx6sTiHSc4j4khk"
profile: Object { gender="male", type="1", picture="http://....jpg"}
This stays like that until I refresh the page using the browser button. After refreshing, Meteor.user() gives all the fields available, while Meteor.users.find() still gives the correct restrictions. (except for the current user of course)
Why does my current user not get all its fields right away? I read about a Meteor.userLoaded() method used to wait for the user to be loaded, but it seems to be obsolete in the latest version.
You're running into an interaction between the restriction of merging fields across publications, and the default user publication which sends the profile field.
First, note that there is a built-in publication that always sends the currently logged in user's entire profile field to that user:
https://github.com/meteor/meteor/blob/devel/packages/accounts-base/accounts_server.js#L1172
Second, merging of fields at more than one level deep is currently not supported:
https://github.com/meteor/meteor/issues/998
What you currently have is an issue where the default publication is sending something like the following
{
username: ...,
emails: [ ... ],
profile: {
... all fields ...
}
}
whereas the publication you have set up is sending
{
profile: {
picture: ...
gender: ...
type: ...
}
}
These get merged on the client according to the rules for how subscriptions are resolved (http://docs.meteor.com/#meteor_subscribe). In particular, see the last paragraph. Meteor knows to merge the username and email fields with the profile field. However, it doesn't do this merging at the inner level. So one of the profile fields will get chosen arbitrarily to show up in the client's collection. If the first one wins, you will see profile.likes. If the second one wins, you won't.
It's likely that this behavior is somewhat deterministic and changes depending on whether a normal login handler is called or a resume handler (i.e. when reloading the browser). Hence why it looks like it hasn't loaded.
As Andrew explained, and as I kinda thought, what happened is that there is another "hidden" publication for the current user, which conflicts with mine. All I had to do in order to fix this was to simply exclude the current user from my publication, since it is already fully published by default:
Meteor.publish('users', function () {
return Meteor.users.find({_id:{$ne: this.userId}}, {fields: {'profile.picture': 1, 'profile.gender':1, 'profile.type':1}, sort: {'profile.likes': -1}});
});
This simple $ne does it for me.
I want to update my user status to be online, meaning, run this code (coffee script...)
Meteor.users.update _id: Meteor.user()._id, $set: 'profile.idle': true, 'profile.online': true if Meteor.user()?
I don't know where to put it, (is it ok to put it in client? ) where will this code run for sure with the logged in user even if user already logged in before ?
from little googling I found that meteor start events is not the place, what is the place?
client side in a Deps.autorun block would do it
in js it would be something like
Deps.autorun(function(){
if(Meteor.user()){
Meteor.users.update(Meteor.userId(),{$set:{<your fields here>}});
}
});
--
if you are trying to detect that users are online and can use meteorite, you might want to check out https://atmosphere.meteor.com/package/profile-online
you could also roll your own, by setting up a Meteor.setInterval call every 10 seconds or so to update a lastSeen time for the user, then detect if the user is online if lastSeen > timeNow - userTimeout[60 seconds?]
I am using Meteor 4.2 (Windows) and I am always getting the "update failed: 403 -- Access denied. Can't replace document in restricted collection" when I am trying to update an object in my collection. Strangely I had no problem inserting new ones, only updates are failing.
I tried to "allow" everything on my collection:
Maps.allow({
insert: function () { return true; },
update: function () { return true; },
remove: function () { return true; },
fetch: function () { return true; }
});
But still, this update fails:
Maps.update({
_id: Session.get('current_map')
}, {
name: $('#newMapName').val()
});
Is there something else I can check? Or maybe my code is wrong? Last time I played with my project was with a previous version of Meteor (< 4.0).
Thanks for your help.
PS: Just for information, when I do this update, the local collection is updated, I can see the changes in the UI. Then very quickly it is reverted along with the error message, as the changes has been rejected by the server-side.
Alright, the syntax was actually incorrect. I don't understand really why as it was working well before, but anyway, here is the code that works fine:
Maps.update({
Session.get('current_map')
}, {
$set: {
name: $('#newMapName').val()
}
});
It seems like it must be related to what you're storing in the 'current_map' session variable. If it's a db object, then it probably looks like {_id:<mongo id here>} which would make the update finder work properly.
I ran into the same issues, and found the following to work
Blocks.update {_id:block_id}, {$set: params}
where params is a hash of all the bits i'd like to update and block_id is the mongo object id of the Block i'm trying to update.
Your note about the client side update (which flashes the update and then reverts) is expected behavior. If you check out their docs under the Data and Security section:
Meteor has a cute trick, though. When a client issues a write to the server, it also updates its local cache immediately, without waiting for the server's response. This means the screen will redraw right away. If the server accepted the update — what ought to happen most of the time in a properly behaving client — then the client got a jump on the change and didn't have to wait for the round trip to update its own screen. If the server rejects the change, Meteor patches up the client's cache with the server's result.