SchultzColeen27: Where’s it Up?

nospam@example.com (SchultzColeen27) — Sun, 15 Aug 2010 01:53:03 -0400
I had got a dream to make my business, however I did not earn enough of money to do it. Thank goodness my close dude recommended to utilize the home loans. Thence I took the short term loan and made real my desire.

LornaJane: Where’s it Up?

nospam@example.com (LornaJane) — Mon, 02 Aug 2010 04:31:13 -0400
Thanks for the write-up, a very neat setup and a very nice explanation of how the various well-known components hang together to make the whole thing works!

Paul Reinheimer: Memcached Constants - Lame Code

nospam@example.com (Paul Reinheimer) — Thu, 29 Jul 2010 16:53:13 -0400
I scraped the content off the doc page, then iterated over everything and echo'd them out.

It was a lame way to do it, so clearly I needed to blog about it to the world

Andrei added a new function to a recent release getresultmessage() which should give you a string rather than the number.

Jay Paroline: Memcached Constants - Lame Code

nospam@example.com (Jay Paroline) — Thu, 29 Jul 2010 16:25:02 -0400
Thanks for posting this, I was having a hell of a time finding out what #s corresponded to what constants. For some reason I couldn't find it in the source either. Where did you get these from?

EllisGL: The accountability problem - Concluded

nospam@example.com (EllisGL) — Sat, 19 Jun 2010 01:52:30 -0400
My thoughts are you have two solutions because this sounds like a small scale application. By small scale, I mean, the number of reads/writes are low and the amount of data being dealt with isn't huge and the grow of the DB will probably be small.

MySQL:
Use InnoDB, with solution #2 and FK's and create a "JOIN" table.

MongoDB:
Store the history as an "Embedded doc"

Of course proper indexes are always the must for both.

Storing schema-less data I can see working, but why add another layer?

Dennis J.: XHGui Improvements

nospam@example.com (Dennis J.) — Mon, 14 Jun 2010 22:17:17 -0400
I guess since licensing is only concerned with distribution rather than usage as long as people only use the software they are ok. You should probably clarify though that the software may not be redistributed or forked.
Looking at the github page I see that two users have forked to code already. I'm not sure if that happened before or after the introduction of the highcharts code but as of now the license file does not permit redistribution in any form so technically they don't have a right to make their forks available to others (which they automatically do on github).

I think it would be best to ask the Highcharts guys to actually give you a proper license that defines the terms of distribution in the same way the jquery code already does with the MIT or GPL licenses.

The default is that nobody can distribute or copy that code in any way and any exceptions to that have to be explicitly granted in the license by the original copyright holder.

Paul Reinheimer: XHGui Improvements

nospam@example.com (Paul Reinheimer) — Mon, 14 Jun 2010 16:00:08 -0400
Hi Dennis,

Thanks for giving me the opportunity to clarify this. There is a readme for highcharts where I think I explain things a bit better.

If you're using Highcharts inside XHProf, you're in the clear. Regardless of what type of website you're running it on (including commercial websites), or what your situation is (e.g. consultant), you're fine. The license has already been paid for. If you want to take highcharts and use it elsewhere on your site, you're going to need to handle that separately.

Does that allay some of your concerns? Also, how could I explain that better inside the license file?

Dennis J.: XHGui Improvements

nospam@example.com (Dennis J.) — Mon, 14 Jun 2010 15:55:51 -0400
You mention that you obtained "a license" for highcharts but the license file doesn't contain the actual licensing terms or a reference to them.
Unless you provide actual licensing terms for the code included the legal situation around it is pretty ambiguous and any use other than "private" will technically require to obtain a commercial license from you and Highcharts. Was this fairly major change in licensing intended?

Lukas: The accountability problem - Concluded

nospam@example.com (Lukas) — Wed, 26 May 2010 02:21:40 -0400
you option #2 should be modified. basically every UPDATE you do to your normal table should still happen + an INSERT into your history table (with the PK being the PK from the original table plus a timestamp). there is no need for an active column. this is how the Doctrine Versionable behavior works.

Brian Moon: The accountability problem - Concluded

nospam@example.com (Brian Moon) — Tue, 25 May 2010 16:42:01 -0400
Yeah, we use #2 as well for stuff where we want to keep the main table lean and mean.

Morgan Tocker: The accountability problem - Concluded

nospam@example.com (Morgan Tocker) — Tue, 25 May 2010 16:18:52 -0400
Hi Paul,

You asked me what I thought earlier, so I'll reply here -

I'm not completely opposed to the serialization method, provided that:

(a) You don't need to search.
(b) You always read/write serialized objects one at a time.

I wrote about this in January:
http://www.mysqlperformanceblog.com/2010/01/21/when-should-you-store-serialized-objects-in-the-database/

The only other advice I might have about the serialization technique, is make sure your code handles that there might be multiple versions of the serialization.

Re: Backup strategies, if it becomes a lot of data, it may become worth while to segment your backup. Every week or month copy inactive data from your 'hot' tables to a series of archival tables, then do a complete backup. But every day, just backup the hot tables.

This has the advantage of very fast recovery times post-disaster, since users probably won't care if it takes you a few more hours (or days) to recover the less vital info.

Avi Block: The accountability problem - Concluded

nospam@example.com (Avi Block) — Tue, 25 May 2010 16:13:42 -0400
How about option 3, but you store the information in a NoSQL database (like MongoDB), where it can be queried efficiently

Joelle Tegwen: The accountability problem - Concluded

nospam@example.com (Joelle Tegwen) — Tue, 25 May 2010 15:50:45 -0400
I found this article http://www.jasny.net/articles/versioning-mysql-data/ a while ago that has triggers for creating a history table and a script for converting existing tables.

Brian Moon: The accountability problem

nospam@example.com (Brian Moon) — Tue, 25 May 2010 14:52:35 -0400
Not completely true. NULL is not considered as part of a unique key. So, you can have 1 or NULL and it will be allowed. Major hackery no?

Dennis Birkholz: The accountability problem

nospam@example.com (Dennis Birkholz) — Mon, 24 May 2010 08:42:03 -0400
That will not work! If you make id+active unique, there can only be one active and one inactive revision, not more than these two!