I have a model which has timestamped entities. Now I want to do bucketing - "buckets" of entities which can be reasoned about a single entity. Also I want to be able to access related entities from a bucket and get a bucket of those entities.

My main concerns are an implementation of bucketing itself and architecture of code behind this.

  1. Should I create a separate model for bucketed data, or should I implement tools to work with the existing model?
  2. As I already have a metamodel with all the subclasses and relations I'd like to be able to easily add bucketing on top. I have been thinking about subclassing all the entity classes to create a bucket-entity class which would extend their common bucket functionality with traits.
  • What language are you using?
    – benathon
    Dec 3, 2013 at 0:34
  • @portforwardpodcast smalltalk, but in general it does not matter that much, let's think about general OO language with trait support
    – Uko
    Dec 3, 2013 at 7:14
  • Wouldn't this be a View (or ViewModel) operation not a Model operation since the output (for whatever purpose) is a derived value? Jan 22, 2014 at 15:41

2 Answers 2


Without knowing your metamodel, assuming that you want to respect it, any response is likely to be flawed. Your problem sounds like it could be solved by different kind of approaches. I'll explain some and you can pick one! ;)

Inheritance You could create a parent to all objects which implements all methods of the sub-class and features the bucket, a list or map of some kind. The implementation would be up to you.

Using an interface You could create an interface that offers all the methods you require and then create two kind of objects. Your bucket and the item contained in the bucket. Both would, implementing the interface, expose the methods you need.

Wrapping files You could use any of the two above while wrapping the files of your project with another object. You could then implement the bucket independently of the object it should hold as you will always just throw the wrapper object into it.

Whatever you choose, all of these have their drawbacks and advantages. As I said before, without knowing more, it is hard to really address your issue.


It seems like the buckets are very simple to calculate based on the timestamp divided by a number. For instance timestamp/60 this would give you buckets of 1 minute long.

If you don't need to permanently store buckets, I would write a function that iterates through all the events and returns a hash of lists. Where hash[23100517] returns a list of all events in that bucket. Then you can just work with this hash. Also finding the bucket of a new entity is very simple. You could even write a member class that was like:

  return floor(self.timestamp / seconds);

and then call this with 60 or whatever your bucket size is.

  • Yes, calculating bucket is easy, but question is different. Let's say we have a project and project has a versions of files. So if you want to get a projects bucket from there files bucket it's easy: you just collect or related projects and remove duplicates, now going from projects to file versions is not the same. Also imagine I can calculate LOC delta with a previous version of a file, so I want to be able to calculate it for bucket. This means that bucket's and bucketed entities should share "interfaces".
    – Uko
    Dec 3, 2013 at 7:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.