Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Laura and me thought of a new better name for SQL Buddy for CUBRID. We suggest "CUBRIDWebAdmin" - a shorter and more self-explanatory name for this application.
Please let us know when you can change the name.
A small suggestion:
What about having a "space" between "CUBRID" and "WebAdmin"?
We would get "CUBRID WebAdmin", which might be easier to read and understand…?
CUBRID WebAdmin sounds and looks better. Thank you Rienzi!
"CUBRID WebAdmin" sounds good and we plan to make the name change when we will upload the version on cubrid.org.
I have several urgent issues with the WebAdmin.
1. SQL Buddy for Cubrid 1.3 - Release Notes.txt should be updated with the next version same as README.SQL Buddy for Cubrid.txt, which has the broken link as well.
2. For all applications that we port we have to make sure the users use it. Otherwise, no sense. On our side one of our CUBRID DBAs said that overall WebAdmin might be useless for them because there is no client-side logging system. Currently, as I checked, CUBRID server does logging inside the "w:\usr\local\cubrid\log\broker\" directory when using the Uniform Server. What our DBAs need is WebAdmin with similar functionalities as the CUBRID Manager. At this moment, WebAdmin has everything except client-side logging. They ask to add this feature, so that super DBA can see in the browser under, let's say, "Live Connections" the information who is connected now, what do they do, all their activities. So, briefly, similar to CUBRID Server logging but so that they can see the logs on the browser. Without it, they will not use it.
Please reply to this post whether you can implement this feature by the next release when CUBRID 3.0 is released.
2. As you probably know, CUBRID WebAdmin is build in PHP and is using CUBRID PHP API which has limited functionality exposed. The limitation of CUBIRD WebAdmin are the limitation of PHP API.
The feature you mentioned is nice to have but cannot be implemented with the functionality exposed by the current PHP API. In fact I think that this cannot be done from any other CUBRID API (only CM does this by connecting to the special port 8001).
If you think of parsing the log file that the server makes in order to retrieve such information (in case that files contains it), I think that would not be a feasible solution.
For the moment (until new enriched version of CUBRID PHP API will be released) the only thing that we can do is to dump the content of the CUBRID Server log file into the browser.
welcome back to real world.
I think cubrid webmanager can write very simple access logs parcing from Apache Webserver logs. Apache web logs contains every request from the beginning however cubrid webadmin can only show access logs like cubrid manager logs. If possible to fix it, please consider this feature.
2010/09/09 17:53:49 - 127.0.0.1 - rejected
2010/09/09 17:53:54 - 127.0.0.1 - rejected
2010/09/09 17:53:56 admin 127.0.0.1 - connected
2010/09/13 12:18:00 admin 127.0.0.1 - connected
2010/09/13 12:33:17 admin 127.0.0.1 - disconnected
2010/09/13 15:28:30 admin 127.0.0.1 - connected
2010/09/14 13:40:30 admin 127.0.0.1 - disconnected
…so what if the user doesn't use Apache…? What do we do then…?
There are dozens of other free (or not free) web servers and developing something "special" for Apache into the code sounds quite weird from my side… I mean, I never heard of such approach before… Same goes for "parsing" the logs… How do you know the locations of the log files (which can be different for every installation)? And even if yoiu know it, is giving access to the app to that folder is a good security practice…?! and there are other open questions as well…
The real problem here, as Catalin already clearly explained, is the limitations build into the Cubrid API…. **
If we really need such functionality, then what it takes is to implement the equivalent MySQL SHOW PROCSSELIS**T!
That's all… So it is actually the "core" team to talk to about this request and once this command is implemented, it will also be added in the PHP application - no problem to do that.
yep. you're right.
since internal services in our corp use apache webserver dominantly as well as other services in Korea, I thought that way.
I'll ask the core team if they have a plan to develop additional db information functions. Thank you.