v4.98 breaks plugins that use the date added on mapper database

I've updated to the latest version 4.98.

There was a notification that the GMCP mapper database required an update. This ran successfully. The messages showed that the date added column was removed.

This has broken a well used plugin that uses the date added for querying the database.



The plugin just seems to use it to order the select query.

I'm not that familiar with SQL or the columns in the table.

Does anyone have a suggestion of what it can be replaced with? Or perhaps just needs removing?

Edit: In the interim removing the r.date_added ASC fixes the plugin. Will wait to see if there is a better suggestion.

Dak

That's an Aardwolf MUSHclient Package message that has nothing to do with MUSHclient itself.


You don't say what plugin. Anyway, this isn't really the place to ask. Maybe on Aardwolf?

My short response without knowing what the plugin is or why it's using that column is that sorting anything in the mapper by date_added is dumb. Don't do it.

You're right Fiendish.

I didn't mention the plugin as you rightly pointed out it's aardwolf related and not mushclient.

However, as there is quite a close relationship between the two that perhaps someone could suggest a fix in regard to knowing what the date_column was used for, not specifically the plugin itself.

If the administrator could delete the post that would be appreciated.

Dak

I think we'll leave the post here in case someone else has that problem.

Well if someone else has the problem and wants help they'll need to show what the plugin is. :)

What plugin is it, then?



Yes the original post was strangely non-specific.

You could always change that to:

That will of course change the ordering. And without knowing what the plugin does or why it wants that order from the datastore of a different plugin, it's a good bet that the outcome will be undesirable.

To clarify the circumstances...
I made a change to my Aardwolf mapper database schema, and another plugin stopped working because I removed the column "date_added" which has no practical value and could have its data changed at any time for any reason.

Now the only thing that could possibly cause this is if this other plugin is manipulating the date_added field to store some tertiary information, because sorting specifically by date_added doesn't make sense otherwise since date_added was entirely arbitrary on my end.

IMO, the only sane thing for this other plugin to do is use its own information storage instead of trying to manipulate the room database that the mapper uses.

The plugin in question is part of WinkleWinkles plugin bundle. The actual plugin is the mapper extender.
WinkleWinkle_Mapper_Extender_4_1

https://code.google.com/p/aardwolf-scriptalicious/

It's at least 5 years on so is in need for some updates.

I would be happy to update it if I managed to grasp what it was doing. As far as I can tell with my limited experience it uses it to determine what's the first room in an area by the first room you visit when you discover that area. It used the date column to determine this.


Dak

There's probably more than one "first room" in an area in any case. After that the date added would surely just be the order in which you explored the area?

Plus even that would be thrown out if you got teleported into the middle of the area for some reason.

As I recall, the existing mapper detects the transition from area A to area B, so that is a more reliable way of knowing what the "first room" in the area is.

Correct. And I explicitly said no to many requests to include shortest-path-into-area in the Aardwolf mapper after implementing it and deciding against it on merits.
This seems to be a plugin that sets a marker associating a particular room with an area keyword.

From what I can tell from a quick peek at the code for the mentioned plugin (I had to dig around and look inside a zip archive), at some point it changes date_added of a manually identified room to be essentially "earlier than everything else" and then later sorts all rooms in an area by date to find that room again.

This is just an obviously terrible idea because date_added can change again from under you. If you already have the room ID, and your goal is to go to that room ID, then just store the ID. Why muck about abusing data that means something else only to do a series of more expensive select queries to get back the information you already had to begin with?

FYI,

Nokfah has very kindly put in a fix for the plugin.

https://github.com/Nokfah/MUSHScripts


Dak