How should I define the Loopback model so that all the properties listed in the model JSON file would always appear on the result even when those properties have no value (or are missing) from the MongoDB record? Should this behaviour be configured in the Loopback or in the MongoDB?
Thanks!
MongoDB is a Schema-less database. It is designed in this way to give us flexibility for adding new fields to a document without any need to restart the database. So I don't think that it is a good idea to handle this scenario on the database side.
I think the best way to handle this could be setting a default value for every property in LoopBack model definition. This solution has a problem when some data is inserted into the database from outside the project.
You can also handle missing parameter at the front-end side.
Another solution that I can think of, is implementing an afterRemote method for checking the existence of all the fields. In this case, you can use this function after any API route that you want to. You can check the following link for more information:
https://loopback.io/doc/en/lb3/Remote-hooks.html#signature
Related
I'm currently in a situation where I need to create a Repository class which would contain multiple financial statistic queries. The queries are not exactly tied up with one Entity but rather with multiple Entities and will select specific data from the database, based on various some conditions.
Having said that, I'm looking for a way to create a Repository class (i.e. StatisticsRepository) which is not associated with an Entity at all, so I could store the queries there. Simply creating that repository doesn't seem to be working. I'm guessing I probably need to create a service of some kind that loads this repo class? Is this correct, and if so is there an example I'm missing in the Symfony/Doctrine docs?
You can just create a class like StatisticsService/StatisticsFinder (naming convention is for you).
That service should have an entity manager injected, so define it in your config.
Create a query builder inside that service, then simply get and return results.
Let's say I have two users, A and B, with IDs 1 and 2 (respectively). Further, let's assume I have two datasources configured: X and Y.
How could I isolate ALL queries issued by user A to datasource X, and all by B to Y for some given remote method? For example, say that A wants to run 'find' for some model via the API - how could I make sure that the only results A will get are those which are accessible through datasource X?
I'm not sure I entirely understand why you would decide a datasource based on the current user, but in any case, I'm not sure you can do that with LoopBack ... at least, not easily. LoopBack is a model-driven framework - everything derives from the model. As such, all API endpoints go through a model (although you can set up custom routes). And each model is connected to a single datasource.
So, if I hit /api/Widget/13 there is no way to make that findById() call switch between two datasources, it will always hit whatever datasource the model is connected to.
Okay, that all said, the solutions I see are to:
Create a "dispatcher" and have that model do the appropriate thing.
Create a custom remote method on your existing model and do the decision making there and the find, etc on the correct datasource.
In either case, it's not straightforward, and not built-in. FYI, if you need to get the datasource you can access it from the LoopBack application object: MyModel.app.datasources.ds1
I have a multi-database Django Project (Python 2.7, Django 1.4 ) and I need that the database used in every single transaction triggered in a request be selected through the url from that request.
Ex:
url='db1.myproject.com'
Would trigger the use of 'db1' in every transaction, like this:
MyModel.objects.using('db1').all()
That is where my problem resides.
Its virtualy impossible include in every call of 'Model.objects' the '.using(dbname)' function (this project already have 2 dozen of models, and its build with scaling in mind, so it could have hundreds of models, and almost everymodel has (or might have) a implementation a of post_save/post_delete that acts as database triggers).
Is there a way of telling django that he should change the default database for this or that request ?
I already have a Custom QuerySet and a Custom Manager, so, if i could tell THEM the database should be this or that could do the trick to (i dont find anywhere how to get request data inside them).
Any help would be apreciated.
I think my answer to a similar question here will do what you need:
https://stackoverflow.com/a/21382032/202168
...although I'm a bit worried you may have chosen an unconventional or 'wrong' way of doing database load balancing, maybe this article can help with some better ideas:
http://engineering.hackerearth.com/2013/10/07/scaling-database-with-django-and-haproxy/
I need to set up the custom schema for bug. I don't plan to do estimation of bug, put them on Agile board, some other fields should be hide also. I need to decrease number of fields in bug for my company users. I tried it several times, but unsuccessfully. Please, provide me steps.
Do I need create issue type schema?
As far as I understand you are interesting in customizing fields configuration for specific issue type. What you need is to setup a field configuration for your case and then map it to a specific issue type in a field configuration scheme. This can be either existing scheme or you can setup a new one. Scheme then should be associated with a project you want these changes to be applied to. This link can also be helpful for you in order to understand the general concept of configuring fields and screens.
I have seen several posts on this site, and on others, stating that the problem is usually caused by the order in which the tables are added to the Configuration of the SyncAgent on the client side, or the SyncAdapter on the provider side. I believe I have my ordering of the tables correctly in both these places (I have an N-Tier architecture - a web service that is providing sync functionality).
Does anyone know of any other potential cause for this behavior?
Also: Sycning works for all tables, except one. For some reason, that table is created on the client but, no records are transferred...even on the initial sync, when the database is created on the client. Any ideas?
Any help would really be appreciated. (getting this sync functionality to work, and then the data entities for the client to use based on the synced data, is turning into a life mission. Don't you just love working with (massive) Frameworks?)
Thanks very much for whatever you can suggest.
[UPDATE: I have found the problem that caused the records for one table to be omitted from the sync, while the records from all the other tables were synced. The InsertId column for the table in question was full of NULL values, and UniqueIdentifier data can't be compared to NULL. The other tables don't have an InsertId column, because they are for download only. Still, the main problem of no Foreign Key relationships persists]
OK, I found this statement:
By default, the following constraints are not copied to the client: FOREIGN KEY constraints, UNIQUE constraints, and DEFAULT constraints
in this document: http://msdn.microsoft.com/en-us/library/bb726037.aspx
So, it appears I have to "manually" create the relationships, once the schema is created on the client.
It is crucial that you add the adapters to the server side provider in the correct order. You also need to make sure that you avoid all multi-table circular references or you will need to write some complicated multi-pass synchronization logic to sync first the tables without the foreign keys and then the foreign keys after the fact. Perhaps a circular reference is why you are losing just the one table. Good discussion of the issue here http://www.8bit.rs/blog/2009/12/replicating-self-referencing-tables-and-circular-foreign-keys-with-microsoft-sync-framework/.
When I was working on this same problem last month, I found that using the INFORMATION_SCHEMA, you can write a pretty good stored procedure to dynamically determine the relationship hierarchy for use in setting up a generic synchronization provider. Let me know if you are interested in something like this...
One workaround for syncing Foreign Key Relationships is explained in my answer here Sync Framework 2.1 Foreign key constraints