We have databases like the below image.
In Application, Once a new company registers a new database created for the company. Consider there might be multiple schemas.
Schemas would be the same for all company.
I am new to NestJS. Currently, we are managing this scenario using function call we pass database name it will create a new connection with DB using mongoose and iterate all defined models in from the database and create an object which used by application-wide.
Now, We need a new level of development. we choose NestJs.
How can we deal with this kind of technique with nestjs?
What should be a design pattern for this kind of flow?
How we will deal with Email for the registered company?
Related
I’m seeing some inconsistent behavior between two different subscriptions when trying to create an Indexer for an Azure Search service through the Azure Portal.
I was able to successfully build the indexers in our test/ppe subscription (Microsoft) using a Cosmos DB collection as a source and the data was matched 1:1 using Edm.ComplexType and Collection(Edm.ComplexType):
Complex Types showing up in dropdown
After I verified things were working as expected, I moved to our prod subscription (AME.GBL) to do the same; however, this ability to add/edit complex types seems to be missing:
Complex Types not showing up in dropdown
Is there a reason why this ability to add complex types is available in one of our subscriptions but not the other?
Is there a feature gate in place for this ability to add/edit Complex types for an index and if there is, would it be possibly to manually override it for a given subscription ID?
Thank you!
Bradley - You are correct that in this case the Complex Type detection feature via the portal 'Import Data' workflow is currently only available via the internal Microsoft portal experience. However, this feature will be deployed publicly world-wide very soon and we are targeting 5/1/2019 for global availability via the portal. If you need to create this index with Complex Types beforehand you can use the API to set the index schema with the complex types directly.
The sample and seed data shows creating a new client in Startup.
This is fine in case of creating a client.
Are there any existing methods or provision for Updating a client. Update involves tracking the existing records from the collection fields within the clients too.
How are entities mapped from IdentityServer4.Models to IdentityServer4.EntityFramework.Entities during an update considering the records are already available in database?
What do you mean when you say client?? If you mean Client for Identity server then you can edit/configure or add more clients or other resources in your config class. While startup, identity server will loads up all the clients by itself, all because of this code:
// Add identity server.
services.AddIdentityServer()
.AddTemporarySigningCredential()
.AddInMemoryIdentityResources(Config.GetInMemoryIdentityResources())
.AddInMemoryApiResources(Config.GetInMemoryApiResources())
.AddInMemoryClients(Config.GetInMemoryClients(Configuration))
.AddAspNetIdentity<ApplicationUser>()
.AddProfileService<SqlProfileService>();
Are there any existing methods or provision for Updating a client.
Update involves tracking the existing records from the collection
fields within the clients too
Yes, you can update client as you can update any other data. Check here how you can use EntityFramework core with identityserver4
How are entities mapped from IdentityServer4.Models to
IdentityServer4.EntityFramework.Entities during an update considering
the records are already available in database?
If you check the IdentityServer4 source you will find AutoMapper is used to convert entities (namespace IdentityServer4.EntityFramework.Mappers). And an extension named ToModel has been provided
We now have one site running but we will need to build a branded site for our client soon. The client site will have exactly the same data set as our current site expect for the user data. The client site must have totally separated user info which allows only the client to use the site.
I don't see the need for setting up a new database or creating a new user table for the client. My tentative solution is add a "Company" column for the user table so that I can differ which site the user data row is on.
I do not know if this approach will work or not or if it is the best practice. Could anyone with experience like this shed some light on this question?
Thanks,
Nigong
P.S. I use LAMP with AWS.
Using an extra column to store a company / entity id is a common approach for multitenant system. In general you will want to abstract the part that that verifies you can only retrieve data you're allowed to a piece that all queries go through, like your ORM. This will prevent people new to the project from exposing/using data that shouldn't be exposed/used.
Can different parts of the the OFBiz application connect to different databases? e.g:
-Party Management => connect to database 1
-Catalog Management => connect to database 2
-Working in the same instance of Ofbiz application.
My plan is to create tenants in OFbiz and have different parts of OFBiz connect to the tenant, while others connect to the default/original OFBiz database.
The short is yes, you can, the long answer is probably you don't want to do that because of existing interapp dependencies at entity level.
First you have to understand how all it fits together:
Ofbiz entities are usually defined in entitymodel.xml and referenced in ofbiz-component.xml Most of the existing components have only this level of configuration. With such a configuration, the entities belong to the default group called "org.ofbiz". Then in entityengine.xml the group is assigned to a datasource:
<group-map group-name="org.ofbiz" datasource-name="localpostgres"/>
This is how a table is assigned to group, then the group is assigned to the database.
So to assign all the entities form a component to a new database what you have to do:
Create a new entity group definition in each component and assign the entities to that group:<entity-group group="org.ofbiz.tenant" entity="Tenant"/>
Reference the group definition from the ofbiz-component.xml
<entity-resource type="group" reader-name="main" loader="main" location="entitydef/entitygroup.xml"/>
In entityengine.xml assign the new group to a different datasource:
<group-map group-name="org.ofbiz.tenant" datasource-name="localpostgres"/>
For an example have a look at olap and tenant groups.
You can do the above steps and have your entities in a separate database, if you are creating a new component or if you want to do that for the components in specialpurpose folder. If you want to do this to existing component from framework or applications folder (like the content component you mentioned) you will notice that components have dependencies (entity relations) and moving some of the entities to a separate database will break that.
I'm exploring all the options to persist user settings. The artilce in the url User-specific settings files for a windows form application: local xml file or database convinced me to store the settings into a db as my application is a standalone communicating with a DB. Is there any provider class like RegistrySettingsProvider to persist the data into database.
No - there isn't anything directly comparable. I'd look at the user settings as just another kind of data to store in the database. Use the same methods to store the user settings as you do the rest of the application's data.
I recommend NHibernate for your data layer. Just set up a mapping file and the database table and let NHibernate handle persisting your data to the database. Use that for all your database storage throughout the app and see how little database code you need to write.
I afraid no because your use setting is very application specific and hence there is no general to do the persistence.
You might want to consider one of the following two approaches:
Serialize your user setting class as a string, and store that string as a blob text column in one of your table.
Create a table schema that maps to your user setting, and persist the setting according to each column.
I would prefer the first approach because of its flexibility.