This project has moved. For the latest updates, please go here.

Manually defining store history

Nov 18, 2014 at 11:06 AM
Transferring Question from the other forum

On Tuesday, 11 November 2014 15:54:04 UTC+10, Matt Cordell wrote:
It seems brightstar uses the actual/real commit time to identify the various historical states of a store.

I have some existing data, that has been developed using an append only method also that I'd like to import into a brightstar store.
Assuming I've broken up the existing data into each of it's historical deltas. (let's say they happened on the 1st of each month).
I was hoping to import each 'monthly delta' as it's own transaction, but keep the respective 'versions'
So
Rather than
November 11 2014 09:20
November 11 2014 09:22
November 11 2014 09:24
...

I'd like to have something like
March 2012
April 2012
May 2012
...

I appreciate I might need to modify my existing version formats. But is it possible to specify a specific value for 'commit time' for when I call ExecuteTransaction() ?

Thanks in advance.
Matt

Hi Matt,

Firstly, please use the Codeplex discussion forum [1] for questions - this forum is deprecated and it would be good to have questions like this recorded in the active dicussion forum.

Anyway to answer your question, the short answer right now is "No" :-( It is not possible to override the transaction timestamp through options to ExecuteTransaction(). I'm not sure it would be right to override the transaction timestamp, however it feels like it might be a nice feature to enable transactions to be "tagged" in some way to allow you to find a particular transaction by its tag - I'll log that as a possible future feature.

Just to probe a little into your use case - is this just to use the transaction information as a way of storing a bit of historic state about the data? Or are you looking to use the historical deltas as a way to control what information is returned by a query (by selecting a particular commit point to query) ? Do you have any date / time information in the data itself ? I'm just wondering if it might be an idea to use separate graphs for each snapshot or to track the deltas in some other way inside the data itself, but the precise approach might depend somewhat on your particular use case.

Cheers

Kal
Nov 18, 2014 at 11:13 AM
Yes! something as simple as a Tag, would probably suffice. I don't really care about the date value - just need some way to identify a specific version (which just happens to be a date). Infact, string tags would probably be better as I could use a uri versioning scheme.

And yes, it's so I can run a query against various versions of the store. That is, seeing how the data looked at a known point in time.

Anyway, thanks for your response. I'm still playing around with brightstar - so don't take my initial question as a feature demand :). I'm still trying to work out how I would use it specifically.
Coordinator
Nov 20, 2014 at 8:54 AM
I think a user-defined tag on a commit sounds like a great idea. I'll have to think a bit about how to implement it, it could be as simple as another field in the commit info, or it could be something more complex to support multiple tags and moving tags from one commit to another or even the possibility of tagging multiple stores with the same tag. I could see all of these as being interesting use cases...

I think I'm going to put this into the 2.0 time-frame which I'm currently using as a bucket for "changes I would like to make but which could break backwards compatibility".

Cheers

Kal