During several years of activity, I accumulated dozens of Database Connections in MySQL Workbench. So many that finding the right one is becoming more and more a challenge. Is there a way to group connections, tidying up the home screen ?
Sure, just right click on connection and choose Move to Group..., then you can create new group or select an existing one.
It's incredible I could not find this on StackOverflow, but googling for a while I arrived to this page: https://dev.mysql.com/doc/workbench/en/wb-home.html
Under MySQL Connections we read
Connection Groups. You may also create groups of connections. Create a group by either right-clicking a connection and choosing the Move to group context menu option, or you may prefix your connection name with the group name separated by a forward slash (for example, "QA/TestBox") when you create or configure the connection.
So basically changing the connection name from
MySystem Connection - Production
to
MySystem Connection/Production
it created a Group Folder in the home screen.
Related
When started charles, java app cannot access redis got below error
redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out
Then I tried to ignore the redis connection to solve it
but the problem still exists
So how to explicitly ignore some connection, e.g redis connection, mongo connection etc. ?
I'm sorry I don't really know what your real problem is. I guess the problem that you have is those HTTP requests still appearing in the Structure view, right?
Being that the case, I would strongly recommend you to use the Focus feature. To use it, you only need to add the domain you are working on to the View -> Focused Hosts... ( you can also do it by right clicking on the request and then selecting "Focus").
By doing this, all the non-focused domains will get grouped in a "Other hosts" entry in the Structure panel so they won't disturb your work anymore.
We are using the inhouse Mongo DB instance. We have 3 multisite solution with 3 websites each.
We are having a debate on whether each sitecore instance have their own mongo DB collection databases (reporting, analytic etc) . Or share one for all instances.
Does anyone has experience on this? Any suggestion would be helpful.
You can happily do this, as long as you want a single view of your traffic. The reporting mostly allows filtering by Site name, so be sure to call your sites different things. Also avoid the temptation to call all the home pages "Home" and use the site name, e.g. Potato Home, Badger Home, etc. The Page-Level reports show the Node's Display Name and they can be confusing otherwise. Imagine Home, Home, Home and Home all as the highest entry pages.
The xDB processing scales fairly linearly so adding 3 sites should be no more processing than if they were all separate, in total. We always use an external processing server and put a Mongo replica secondary on that box. Then in the Mongo connection string set the ?readPreference=nearest. Check the Mongo docs to see the options you can set on the connection string URL.
It will always better to track analytics data independently for a single instance of a website so as you mentioned there are 3 instances of websites with multisite for each of 3. So as per my recommendation you should go with 3 different xDB databases configuration for each physical instances of websites. It will give you a clear data for the reporting as per Instance wise, if more details you want please do comment.
In order to secure our database we create a schema for each new customer. We then create a user for this schema and when a customer logs in via the web we use their user and hence prevent them gaining access to other areas of the database.
Our issue is with connection pooling as it is a bit inefficient to keep creating/dropping new connections for these users. We would like to have a solution that can work across many hundreds of different database users.
We've looked at pg_bouncer, but the issue here is that we have to create a text record in an ini file for each user and restart pg_bouncer every time we set up a customer. This is not a great solution.
Is there an alternative solution that works in real time and would mean a customers connection/connection(s) would stay in the pool whilst they were active?
According to the latest release notes pgbouncer might actually do this. But I haven't tried.
Pooling mode can be configured both per-database and per-user.
As for use case in general. We also had this kind of issue a while ago. We just went with connection pooling with one user/database and multiple schemas. Before running psql query we just used SET search_path TO schemaName. As for logging, we had compliance mode, when we could log activity per customer and save it in appropriate schema.
I'm developing a project here and everytime I need to send a query to MYSQL I'm opening a new connection.
Is this right or should I only connect once? How should I proceed?
Thank you
Probably you should not open a new connection for every query.
There are exceptions to every general rule, of course, but typically you should connect once, sometime before the first query, and then re-use the same mysqli connection object for multiple queries during the given PHP request.
There is no limit to the number of queries you can run in serial using a given connection. The only limitation is that you can run only one query at a time.
Think of it this way: if you were writing a PHP script to simply read a file, and you knew you were going to read multiple lines from the file, you would keep the file handle open and make multiple read requests from it before you close the file. You would not re-open the file every time you wanted to read from it during a single PHP request.
The overhead of opening new connections to the database is reasonably low (at least for MySQL), but if you have an opportunity to easily reduce that overhead, it's likely worth it to do so.
Re your comment:
You're right, there's no way to keep your $mysqli object across pages. That's what is meant by the term request. Objects and resources are cleaned up at the end of a request.
When you said you were creating a new database connection for every query, I assume you meant that if you execute more than one SQL query during a single request (that is, page view), that you would create a new $mysqli object for each query. That would be unnecessary.
There's one other way you can reuse the database connections from one page view to the next. That is to use persistent connections. This doesn't preserve the $mysqli object -- you still have to run new mysqli on each page load. But internally it is reusing the database connection from a previous PHP request.
All you have to do to open a persistent connection in this way is to add the prefix p: to your hostname.
Servers and databases have a finite number of connections available. If every one of your users keeps an open connection for no reason (like when they are reading a blog post for a page that already loaded) then it will cap the number of people who can connect to your project in production. Unless there is a very specific need to keep a connection open, I recommend not doing so.
Again though, it really depends on the scope of your project. If you are just talking about a single page of a website, typically it's fine to leave the connection open until you are done loading the page.
I am working on the jabber chatting Applications with the use of XMPP server .
I want to make 2 user friend so I have to add roster with the use of mysql query.
I have make entry in two tables.(1) ofRoster (2)ofRosterGroups.
I make entry in both the table but its not working.
Is there anything where I am missing.
I can do this with the admin panel but i don't want to do that.
I think you are using openfire (those tables in SQL look like the openfire setup). If so, the table you have to edit is "ofGroupUser". To add a user to a group you need to do a sql insert into that table where the group name is the group you want to add the user to, the username is the user you are adding to the group and administrator is the flag of that user's authority (just use 0). An example insert would look like this:
INSERT INTO ofGroupUser VALUES("group name", "user", administrator);
However, as mentioned in the above post this is not a good method for doing this as it will not immediately affect the server. You must restart the server for these changes to take place because openfire (or whatever server you are using) probably only reads the database on start up. Once it caches everything, it will edit the database according to requests (like adding users or groups through the admin console), but will not read from it and your additions will not be seen until a server restart occurs.
Basically, doing manual sql inserts will produce the desired results, and, if you are just testing some functionality, will work just fine as long as you restart the server. If you are using openfire and need to do group administrative work in some way besides the web ui, I would look into using a different server. As far as I know, openfire isn't real great with administration outside of it's web ui. Here is a list of many open source xmpp servers. I'd recommend ejabberd (as mentioned above post) it has a very nice control tool called ejabberdctl with an available expansion module called mod_ctlextra (here is the man page for it which lists commands) that will allow you to do what I assume you are wanting. Then you don't have to worry about sql and restarting, just use their tool which is how it should be.
Also, on a side note, ejabberd is extremely efficient due to the nature of the language used to write it: Erlang. Great stuff.
Hope that helps!
Presumably you are using the odbc modules with ejabberd. The sql schema though defines two tables rostergroups and rosterusers, not the ones you mention in the question. In any case you should not update the tables directly, ejabberd keeps internal state and does not get notified of your changes.
The way to go is by actually having the users send the mutual subscriptions and accept them as per the rfc. Roster Item Exchange might also be useful.