There seems to have no way to enforce uniqueness in Parse. I have a parse object in which one of the fields is a url. I require that url to be unique as it is the most important field in the object: everything else is meta data about it. So is there a way to override the objectId of a Parse Object? That way I can always check for existence in a simple way before trying to create the object.
Actually this might still fail. So any ideas that do not include cloud code?
I know this can be done because Parse is able to ensure username and email are unique for each User object. I am hoping it's an elegant solution and someone here knows how I might accomplish something similar. After all, database tables with unique fields are commonplace.
Related
During development stage, sometimes I changed the column name of a parse class and my Query.find() is returning the following error
{"code":106,"message":"key objectId not present"}
The parse help says, I am tinkering with the internals of parse. Certainly no.... Is this a known issue? Do i need to clear the session or something like clear the schema cache?
Please help.
Changing a column name in a class on parse server is not (yet) available as of parse server 2.2.9.
I assume you are changing its name directly in the mongoDB so it is clearly tinkering with the internals of parse server.
However you could technically change a column name if you know which data to adapt, e.g. the _SCHEMA collection (only visible in the database, not in the dashboard) has to account for the new name as has the field name of every document in the collection.
The easier way to do it is deleting the column you don't need and creating a new one with the desired name in parse dashboard. And maybe planning a bit further ahead so you don't have to change column names so often ;)
If UUIDs are unique across RethinkDB, I was wondering whether you could get a document having only its UUID, without knowing the table it resides in.
I am thinking of something like:
r.db('test').get('[UUID]').run()
You can write r.db('test').tableList().map(function(table){return r.table(table).get(UUID);}).
As far as I know, all QuickBase API calls are called using the following syntax: http://<quickbase>/db/<dbid>?
Is there a way to get the dbid field without navigating to that database table within QuickBase?
If the above is not possible, would anyone recommend anything other than creating another table that stores the IDs of the tables you want?
With the latter method, I believe I would only need to store one dbid and could pull down the rest (which I believe would still need to be user entered, but would be better than requiring them to change the code).
Thanks for the help!
API_GetSchema will return the list of dbids.
https://www.quickbase.com/db/<yourApplicationId>?act=API_GetSchema&apptoken=<yourApplicationTokenId>&fmt=flat
CouchDB's versioning is an absolute boon to the application I'm writing, but each of the objects I want to represent in the database has it's own unique identifier (let's call it my_id), so I don't really need the _id field.
Is there a way for me to tell CouchDB that I want to make my field the primary hey (not _id)?
I'm using ruby's couchrest_model, so I know I can do Model.find_by_my_id(params[:my_id]) if I've put view_by :my_id in my class, but this feels like I'm storing an _id for no purpose. Should I care?
would it not be possible to, when you create the document, provide your own id instead of the default one couchb assigns? I don't know if ruby's couchrest can do it, but it's available in the CouchDB API
See here: http://wiki.apache.org/couchdb/HTTP_Document_API#PUT
The document ID is passed into the url.
I'm about to embark on a project where a user will be able to create their own custom fields. MY QUESTION - what's the best approach for something like this?
Use case: we have medical records with attributes like first_name, last_name etc... However we also want a user to be able to log into their account and create custom fields. For instance they may want to create a field called 'second_phone' etc... They will then map their CRM to their fields within this app so they can import their data.
I'm thinking on creating tables like 'field_sets (has_many fields)', 'fields', 'field_values' etc...
This seems like it would be somewhat common hence why I thought I would first ask for opinions and/or existing examples.
This is where some modern schemaless databases can help you. My favourite is MongoDB. In short: you take whatever data you have and stuff a document with it. No hard thinking required.
If, however, you are in relational land, EAV is one of classic approaches.
I have also seen people do these things:
predefine some "optional" fields in the schema and use them if necessary.
serialize this optional data to string (using JSON, for example) and write it to text blob.