JDOQL: What is the equivalent of SQL's count(*) in the JDO world?

Displaying large datasets There are often times when you need to display data in a table format and the size of the potential dataset is extremely large and so ends up being represented across many pages and displayed with the usual "previous/next" buttons. Most UI frameworks need to know upfront what is the total count of items you will be displaying so they know how many pages there are and can display some text above the table that says something like: Items 31-40 of 397 Avoiding a big database, memory and CPU hit What you don't want to do is force your JDO ORM (or an ORM using any Java persistence standard e.g. JPA) from instantiating ALL of the objects just so that your UI knows the total count of items to be displayed. To do this you need to perform some kind of 'count' query. In JDO this is done by setting the result set to 'count' but count needs a parameter. e.g. PersistenceManager pm = getPm(); Query q = pm.newQuery(MyClass.class);          /

Upgrade from MySQL 5.7 to MySQL 8 - Do it! Do it now!

Our web hosting application platform Pagebloom has been running on MySQL 5.7 for some time now and it runs brilliantly - it's exceptionally responsive and provides great user experience. The performance of the underlying MySQL 7 has been great except... Clustered indexing: The double edged sword Part of MySQL's great read performance is due to an "under the hood" design feature that most software developers who use it are blissfully unaware of. In the automobile world it would be the equivalent of fuel injection or a turbo/super charger or in German - a Kompresser! These are features that can be added to the design of an engine to provide a significant boost in performance. For MySQL this feature is what is known as a "Clustered Index". The main concept of a clustered index is that the core data of each record is actually stored within the primary key index. Yes, you heard correctly - actual record data is embedded into the B-tree frames that make up the ind

The case against IP 6: When scarcity can be a good thing

With IP 4's limited range of public IP addresses and free IP 4 addresses becoming scarce it makes sense that the world should migrate over to IP 6 ASAP ... or should it? What's an IP address anyway? A bit of background for those who did not know that the internet predated the world wide web by a good two decades or more: IP addresses are kind of like  a physical street address. You write a physical address of a place anywhere in the world on the front of an envelope, put an appropriate stamp on it and then one or more postal services around the world will cooperate with each other to, hopefully, get your envelope to the "TO" address you specified. A public IP address identifies a "place" (e.g. a web server) on the internet where internet "data packets" can be sent. There's a lot of different protocols that can be used to send data across the internet but at the lowest levels they are all based on a simple principle: The internet is basically on

How to reset MySQL 8 root password on CentOS 7 and 8

Occasionally you come up with the world's most unbreakable root password for a MySQL 8 installation and you get distracted before you record it somewhere.... and you remain distracted for 3 months. Then you return to the project where this database was needed and ... whoops! What was that totally awesome password? Here's how you can reset your root password. This was based on a page that had a similar instructions except none of them worked - lots of errors and incorrect names - like referring to mysql instead of mysqld when stopping the service. Here we go: All as root user: Create a file in /var/lib/mysql called mysql-pwd with the following contents: ALTER USER 'root'@'localhost' IDENTIFIED BY 'anotherPwd28^$94'; Shutdown mysql   systemctl stop mysqld Run MySQL executing the given init file under the mysql user   mysqld --init-file=/var/lib/mysql/mysql-pwd --user=mysql & Check the MySQL log to make sure no errors occurred:   vi /var/log/mysqld.log

Asynchronous notifications from the server to the browser - perfect

This is why I love Wicket Java Web UI framework. It provides all the power of the latest JavaScript and browser capabilities without ever having to write any code in that crazy, non type safe, interpreted JavaScript language ;) Wicket components have all of the required JavaScript embedded within them meaning a Java developer of any skill level can simply instantiate a few components, add them to a page and bang! - too easy. So about asynchronous notifications... The 'status update' problem Often within a web app the user will invoke some operation that can take some time. The page or part of it needs to be updated to reflect the new status after the operation has completed. To do this developers, traditionally, have had to do one of these: Make a request to the server which the server delays responding to until the operation has completed. This is inviting bad karma to your web server because it ties up a connection and the number of connections in a web/app

I'm coming clean. I'm letting everyone know that I'm a bug addict...

The other day I added a new, rather complex feature to our Filegroove product. I did the normal planning and then analyzed the pros and cons of a few different design implementations. I then went ahead and implemented the chosen design and ... ... it was a bit of an anticlimax when it basically worked as designed, first go 🙂 Normally I have the excitement of hunting down some tricky bug that needs super detective skills because of some incorrect assumption I had made or due to some oversight but no ... the damn thing just worked! My reaction made me ponder: I think I've become addicted to the dopamine hit I get when I solve a tricky bug. I miss that when everything just works - need to get my dopamine hit from somewhere else - maybe some FB pings? LoL! Here's my official admission: I'm a bug addict. I've been using bugs for many year now. I tried to get off the bugs but its just too hard. After a few days without bugs I can't sleep at night and go

Git and Subversion - the working directory is fundamentally different

One of the fundamental differences between Git and Subversion that I didn't understand at first and, IMHO, doesn't really get much coverage in the documentation is the way the 'working directory' is treated. Git is all about branching and it is indeed very good at that but what happens when you switch branches in Git is completely different to when you switch branches in Subversion. You could say that you never really "switch" branches in Subversion. You can create branches and checkout a branch in subversion: In subversion if you want to use a branch you typically 'check it out' to a new clean 'working directory'. This directory is a new place in your filesystem and you perform work on that branch in this new working directory. You can't easily 'switch' a working directory from one branch to another branch. With subversion if you are working on a number of different branches then you would typically have a number of different