So in my /config/environments/*/database.json under my connections field, I declared another DB connection to redis.
I know accesing the model will fall down to the default ( which is MongoDB for this scenario), but how can I use my redis connection if I want to use it instead of the default?
If you are using the content type builder plugin to create a new content type, in the modal where you chose the content type name, you will see a dropdown for the connection you want to use.
If you have already created the content type, in the ./api/:name/models/:Name.settings.json file you will see a connection key.
You will have to replace the value with your connection name.
Related
I would like to know if it's possible to set the database in a connection at runtime (nestjs with TypeOrm and postgres). I'm having a system where there are many tenants and each one has it's own isolated database. The structure of the databases are all exactly the same and i want to use the same entity classes in my code.So after a user logs in, i want to set the database name to be used at runtime.
I cheked few solution working with : Connection, createConnection, getConnectionManager of'typeorm' , which are deprecated , i Wonder if this is possible with DataSource and how can i implement named connection with dataSource (equivalent of getConnection(tenant.name))
ps: i am using '#nestjs/passport' guards
Thanks.
In IIS, I can configure any number of DB connection strings on a given node:
When creating a new connection string, I can enter any name I like into the Name text box:
However, when editing the connection string, the Name text box is read-only:
Why is it read-only? Am I not supposed to change a connection string's name?
Note that I can still change the name, of course, by editing the underlying Web.config file manually. And that is indeed what I've been doing several times now, but the fact that the UI won't let me change the connection string name after it has been created makes me wonder whether there are any problematic side-effects that I'm not aware of.
Background: The framework of the project I'm working on uses a fixed connection string name, "Default", to load the connection string in plenty of places. This way, quickly switching to another DB can only be done by renaming the connection string in IIS to Default, rather than changing some application setting to temporarily use a differently named connection string.
You can change the IIS site connection string name if its entry type is local. just click on the connection string in which you want to change the name and click on the rename from the action pane.
another way is to use iis configuration editor.
1)open IIS manager, select your site/virtual directory or application.
2)click on the configuration editor feature from the middle pane.
3)in configuration editor windows select the connection string from section drop-down:
4)click on the three-dot from the collection, select your connection string, and change the name and close the window and apply the changes.
I am using nodejs, Mongoose and mongodb database.
Sometimes I have seen that if I drop a database that included some collections inside it, when I run my node which makes some collections inside the database ( with the same name ), then the information that I want to save as a new entity does not show correctly.
I need to also mention when I drop the database in mongo db shell I also manually delete all the catch files inside c:/data/db ( default mongo db folder).
I checked the mongo documentation, sometimes it could make a problem if you make a database with the same name of the deleted database. Located at https://docs.mongodb.com/manual/reference/method/db.dropDatabase/#db.dropDatabase
You answered your own question. The document you have linked describe the solution:
Warning: If you drop a database and create a new database with the same name, you must either restart all mongos instances, or use the flushRouterConfig command on all mongos instances before reading or writing to that database. This action ensures that the mongos instances refresh their metadata cache, including the location of the primary shard for the new database. Otherwise, the mongos may miss data on reads and may write data to a wrong shard.
I'm confused how to explain myself well here is my scenario.
I have a database named "database1" and i have used typed dataset in visual studio and have added more than 200 stored procedures in the table adapters.
it is a desktop based application. now i want to deployee the same software in other school same database but i have changed the database name
when i generate new database from query and write all the stored procedures in the database and change the database name in the connection string it doesn't work.
I'd recommend you don't change the database name, or if it's something specific to the first client (like ParisTechnicalCollegeDatabase), change it now to something generic (SchoolManager) so you never have to change it again. There's no specific problem I can think of regards reusing a typed dataSet on a different database: I do it daily on database that aren't clones of each other. Ensure your second server is set up with a user and default schema that is specified in the connection string. The problem will eithe per be faulty connection string or incorrect database setup, not the fault of the dataSet
For more targeted help, post up the error messages that appear when you try to run your app on the new database
Can anyone tell me the best practices for keeping DB data private and only stored on the DB of a web server? I'm running a Node/MongoDB/Mongoose/Express stack.
I've got hashed password fields in the db in the User objects and obviously don't want that getting pushed out to the client end when the User data is sent out.
Currently, I'm just manually deleting the properties off of the User objects before I hand it off to Express but that just seems a bit hack-tastic. Is there a mechanism in Mongoose or Express that lets you delineate private properties that are not supposed to be sent out over the wire and only used internal to the server?
When you retrieve an object from the DB that includes those fields, then they are part of the object. Deleting them from the object before sending them out is not hack-tastic at all. Your only options are to:
delete the properties before sending it to the response
map only the fields you want to a new object and send THAT out with the response
use a different query which excludes those properties when dealing with public-facing objects