I am using react-native-firebase, and I generally want to use custom keys on the table's JSON objects. I have searched and I know that I can use the set method instead of push, to accomplish that. My problem is when creating new users.
React-native-firebase uses the function signInWithEmailAndPassword(email,password) which automatically creates a new user with a random ID like 9dBqfh5yfbd2dMGIieIe3tPs2ba2. Now since I am used to mySQL database structure, instinctively I would like to use either a numeric key, or even the username as an ID. However I am not really sure if the corect way to store the uid on the database is on the object's key, or inside the object on a uid property.
Is there any way except from using the admin SDK which requires of course a server and cannot run natively on my application to achieve this?
You can set custom UIDs while creating a user using the Admin SDK only. You can store both the random ID and the integer along with other user info in the database if necessary. For example if you are using Firestore then a document can be like:
{
uid: 'firebase_auth_id',
num: 1,
...otherUserInfo
}
Now since I am used to mySQL database structure, instinctively I would like to use either a numeric key, or even the username as an ID
It's quite common to use such random IDs in NoSQL databases instead of integers (like UUIDs as key in SQL). Storing such sequential IDs might lead to hotspots and is not advised as mentioned in Firestore's documentation.
If you need the ID to an integer for querying/sorting purposes then you can store a createdAt Timestamp field instead.
Related
My users' collection used to like:
{'_id':'xxx', 'hobbies':['Dance','Ski']}
Now I add "likes" as:
{'_id':'xxx', 'hobbies':{'Dance':5,'Ski':8}}
I want to query users have at least one same hobby, my old query is like:
db.usr.find({'_id':{'$ne':usr['_id']}, 'hobbies':{'$in':usr['hobbies']} })
Now my query is like:
db.usr.find({'_id':{'$ne':usr['_id']},
'hobbies':{'$in':list(usr['hobbies'].keys())} })
I checked out mongodb documents, found nothing to represent 'hobbies' field name, or python's dictionary key. For mongodb, new 'hobbies' represents embed object, the field name is usually definite.
Do I HAVE TO maintain two arrays(in mongodb) or lists(in python)? Isn't there a simple solution?
{'_id':'xxx', 'hobbies':['Dance','Ski'], 'likes':[5,8]}
Unfotunately, mongodb does not support querying/filtering field names.
Your options are:
do the filtering on client side, after querying in full
keep hobbies names in an array, like you used to, in order to be able to filter on server side
I'm having spleepless night thanks to Asterisk Realtime.
I have some trouble understanding the documentation ( like http://www.voip-info.org/wiki/view/Asterisk+RealTime+Sip ). Too many tables, many parameters, fragmented informations, no exhaustive tutorial.
I have simply to auto-register some users from an external MySQL's table ( id, user, chatkey ).
Which are the columns i HAVE to set to get it work? If there where simply a user and password column, I would have matched them with my.user and my.chatkey, but now I'm very confused.
Is there any side effects using VIEWS instead table + triggers?
You have set ALL columns. Minimum set is something like type,username, host,name,nat,allow,disallow.
You can do it using mysql view from your current tables.But if you do so, you have use cache of realtime friends or organize contact update(update&store of all fields below&including ipaddr). Otherwise your setup will not able determine where your sip devices.
I don't understand your issues. Wiki is very clear. For sip auth you need only one table sip_buddies
and need put in /etc/asterisk/extconfig.conf
sipusers => mysql,general,sip_buddies
sippeers => mysql,general,sip_buddies
note, general - name of already setuped(in /etc/asterisk/res_mysql.conf) database connection.
From your question i see you not understanding asterisk internals, so i recommending you read Orely's book "Asterisk the future of telephony" or hire expert. Otherwise resulting application will be not scalable and probably will work strange.
I have a User ndb.Model which has a username StringProperty that allows upper en lower case letters, at some point I wanted to fetch users by username but have the case forced to lowercase for the filtering. Therefor I added a ComputedProperty to User: username_lower which returns the lowercase version of the username as follows:
#ndb.ComputedProperty
def username_lower(self):
return self.username.lower()
then I filter the query like so:
query = query.filter(User.username_lower==username_input.lower())
This works, however it only does for users created (put) after I added this to the model. Users created before don't get filtered by this query. I first thought the ComputedProperty wasn't working for the older users. However, tried this and calling .username_lower on an old user does work.
Finally, I found a solution to this is to fetch all users and just run a .put_multi(all_users)
So seems like a ComputedProperty added later to the model works when you invoke it straight but doesn't filter at first. Does it not get indexed automatically ? or could it be a caching thing.. ?
any insight to why it was behaving like this would be welcome
thanks
this is the expected behaviour. The value of a ComputedProperty (or any property for that matter I guess) is indexed when the object is "put". The datastore does not do automatic schema updates or anything like that. When you update your schema you need to either allow for different schema versions in your code or update your entities individually. In the case of changes to indexing you have no choice but to update your entities. The MapReduce API can be used for updating entities to avoid request limitations and the like.
I'm noticing that when I do a query such as the following:
https://rally1.rallydev.com/analytics/1.27/41529001/artifact/snapshot/query.js?find={ _Type: "HierarchicalRequirement",ScheduleState:"In-Progress",__At:"current"},fields=true
My results collection is coming back with this:
{"_rallyAPIMajor":"1","_rallyAPIMinor":"27","Errors":[],"Warnings":[],"ThreadStats":{"elapsedCpu":"10.0","waitTime":"0","blockedTime":"0","waitCount":"0","blockedCount":"0"},"Timings":{"preProcess":10.0,"findEtlDate":0.0,"allowedValuesDisambiguation":0.0,"mongoQuery":0.0,"authorization":0.0,"postProcess":0.0,"other":0.0,"TOTAL":10.0},"GeneratedQuery":{"find":{"ScheduleState":{"$in":[41529076]},"$and":[{"_ValidFrom":{"$lte":"2012-05-23T18:25:41.363Z"},"_ValidTo":{"$gt":"2012-05-23T18:25:41.363Z"}}],"_ValidFrom":{"$lte":"2012-05-23T18:25:41.363Z"}},"workspace":41529001},"TotalResultCount":2205,"StartIndex":0,"PageSize":100,"ETLDate":"2012-05-23T18:25:41.363Z","Results": ... RESULTS HERE
I'm curious about this aspect:
"ScheduleState":{"$in":[41529076]}
Which shows the ObjectID (OID) of the Schedule State rather than a String value. Is there an easy way to get back Schedule State strings instead of OIDs? What's the best way to lookup the mapping from Schedule State OIDs to Strings?
Update: The Lookback API has recently been upgraded to include hydrate functionality to address this issue. Here's how it works...
Hydrate
By default, during the response, this API does not attempt to disambiguate drop-down field values from their native ObjectID integer form into strings. However, you can specify some fields to be hydrated using this syntax:
hydrate: ["State", "ScheduleState"]
This will disambiguate the State and ScheduleState fields back into strings. Note, the Analytics API is using the current allowed values to do this disambiguation. It's possible that there are older values referenced in the snapshots. Those OIDs will not be disambiguated.
I have a collection which contains both _id and id field. When I search by id field in mongo client everything is fine. When I search through mongomapper model like: Product.find_by_id(6) or Product.where(:id => 6) it return empty Plucky object and I can see that it looks for an _id field instead of id.
As I understand mongomapper just always using _id, no matter if you specifically want to find something by id.
Is there any work around for it or I'm doing it wrong?
I believe MongoMapper treats id and _id both equally. id is just a friendlier representation of _id.
In your particular case, is there any reason that you need to have the id field as well? I'd recommend changing that, particularly if there is another more descriptive name which would fit. If you are actually using the id field as a unique identifier (which it sounds like you might be), the best approach would probably be to store it in the _id field instead. As you will already be aware, this is required on all MongoDB documents and can either be specified by you (your application), or added on later by your driver outside of the scope of your application code.
Hope that helps.
It could be caused by this issue (https://github.com/jnunemaker/mongomapper/issues/195) if you ever had an instance with a key of "id." Mongo remembers every key from every instance, unless you clear the key explicitly.