meta tagging?

All of that is in the mix.  We finished multiple workouts on the dev site awhile ago and have been testing, we are finishing phase two of the logger including power logging (mainly) but also workout types AND keyword tagging of trisport workouts.

THOUGH do we need each 'tag' to have a corresponding user-defined 'units'?  Perhpas this would be more suitable (with the units) for a 'custom logging' area for stuff like glucose levels for diabetics or anything under the sun.

This tagging will be part of a future 'super search/filter/report' that will be able to search every logged parameter.

Temperature and humidity is included too.

I'm really gunning for this by the years end, but it will probably run into January due to testing.  Right now we just ordered some new servers to upgrade to some dual cores before the New Year.

how are you structuring the database for the keyword tagging and how are you going to structure the power searching?  I guess it really depends how much flexibility you are working into the engine or really how much you want to give users.  The simplest way I can imaging is just making all tags free form.  I can structure my tags however I want.  That means I would have to have a lot of control over my search strings.  You could also give each tag several attributes, like name value and unit, then control the format. 

So for glucose, I could log it with method one by just tagging glucose::36 or glucose::36unit or glucose::36_unit or whatever.  I would just have to maintain the same syntax everytime I put it in and formulate my search strings accordingly.  This could be simplified by logging previously used tags for reuse.

The second way I can see would be a little more limiting, but possibly easier to manage.  Every tag has three attributes.  So when I want to tag glucose, I would have three blanks to fill in.  One for tag name, one for value and one for unit.  Then you could generate a common format tag or several tags.  Using the same example,

I could declare name = glucose, value = 35 unit = unit, then the js or php or whatever turns those three seperate values into something like:

glucose::35_unit or even glucose.value::35, glucose.unit::unit

For the second one the unit parameter could be optional....it just depends on how the search strings and reporting work. If all these are stored in the field `runmeta` I could find all records with glucose data by searching for 'glucose' in the field.  If I wanted a particular value, I'd just search for glucose.value:: and construct a regex to fin the value or range of values I want.    The unit would be something that is usefull to have, but not needed at all.   A type.value::hills or type.value::tempo would be a tag that doesn't use or need a unit, but it would still be stored and searched in the same fashion.

If you've ever played around with splunk, I think it gives some good ideas for indexing and reporting on databases.  If you have a spare linux box, install it and set it up to monitor your webserver logs 

No idea!

I know nothing when it comes to programming exept some html, and forget about databasing.  Conceptually, when you mentioned tagging and very specific searches, it sounded similiar to the stuff we have going or planned.

On a somewhat technical note:

Tagging is coming. It's a very useful, relatively simple feature to implement. It's become common enough that some people have come to expect it in just about any data driven web app.

Regex queries: maybe but I'd need a lot of convincing. It wouldn't be useful to that many people, the potential for problems is high and it could use up a lot of time for customer support. The idea of having to provide support for a person just learning regular expressions to create their first query makes me want to run and hide under my bed for a month. Providing it 'as-is' without support isn't an option, anything we create and offer is going to be supported. For anyone who's curious about this, here's how to use a regular expression to search for an email address -'\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b ". Nothing personal folks but I just don't have it in me to do on-demand debugging of others regular expressions.

Read only access to the db via dsn: Highly doubtful. Again, a lot of work for relatively little payoff. The percentage of people who'd find this useful would be far too low to warrant the time and expense spent developing and securing it. Then there are the support implications. We're also not going to publicly expose the db schema of the training logs, and the amount of effort it would take to abstract it for just a few people to use would be much better spent on other features.

You're killing my fun.  I am looking forward to the tagging and other reporting features though.

Once you start talking about support, I can see why regex would be out.  Are you going to include some sort of wild-card operator on the tags? 

I guess I'll just have to write something to parse the csv files into an SQL dump file