Creating super column family through Hector requires downcasting to Thrift

[davidcox66]

The ColumnFamilyDefinition returned from HFactory is immutable and lacking super column operations. This could probably be fixed by having a createSuperColumnFamilyDefinition() with additional super column parameters or by having the method return a mutable sub-interface with applicable setter methods (setColumnType(), setSubComparatorType()).

  ThriftCfDef cfDefinition = (ThriftCfDef)HFactory.createColumnFamilyDefinition( keyspace, superColumnFamily, comparator, new ArrayList<ColumnDefinition>() );
  cfDefinition.setColumnType( ColumnType.SUPER );
  cfDefinition.setSubComparatorType( subComparator );
  cluster.addColumnFamily( cfDefinition );

[zznate]

I'm fine with this - I'm not quite happy w/ how the wrapper classes for the system_* methods ended up, particularly now that avro is "gone".

Let me think about how far into the weeds I want to go on this. In the meantime, if you want to fork+PR with the HFactory method you describe, I'll take it. (If GH is not your forte, a patch file is fine as well).

[davidcox66]

Do you have a preference how you would like this implemented? Adding additional parameters to a addSuperColumnFamily() method might get unwieldy with the sheer number of options you may want to configure. Do you think creating a interface that supports modification would be better? This would allow you to conditionally expose modification where it makes sense, such as when adding a new column family, and lock down to read-only mode as you have already done most other places. See code below:

I haven't gotten involved in GH yet but it will make sense for me to make the effort. I've been working on something else I'd like to contribute. I'm clearing that with the boss. I think they won't have a problem sharing it. I've implemented something similar to the Spring Framework's JdbcTemplate to simplify common object to db operations. It fills a gap in functionality where Hector provides primitive type operations and the Hector Object Mapper provides full blown JPA. This resides somewhere in the middle, allowing you to concisely map objects where the JPA route may be overkill.

public interface MutableColumnFamilyDefinition extends ColumnFamilyDefinition { public void setComparatorType( ComparatorType type ); public void setSubComparatorType( ComparatorType type ); public void setColumnMetadata( List columns ) ... } MutableColumnFamilyDefinition def = HFactory.createSuperColumnFamily( keyspace, superColumnFamilyName ); def.setComparatorType( type ); def.setSubComparatorType( type ); cluster.addColumnFamily( def );

[zznate]

Good point about addSuperColumnFamily.

If you want to take a stab at this in depth I would say have at it as you see fit. My only guidelines here are:

• I don't care about keeping things immutable
• I feel more like every time I look at it, it seems like more of an "too many interfaces" anti-pattern

PM coming with regards to the spring stuff. Yes in short.

[ghost]

What is the status of this? I'd like to be able to create a SuperColumnFamily

[zznate]

This issue has not received any love yet. You can create SuperColumnFamily manually still, just not through HFactory.

[ghost]

What is the main holdup at the moment?

On Nov 14, 2011, at 5:27 PM, Nate McCall wrote:

This issue has not received any love yet. You can create SuperColumnFamily manually still, just not through HFactory.

---

Reply to this email directly or view it on GitHub: https://github.com/rantav/hector/issues/180#issuecomment-2732478

[patricioe]

I'll take this issue. Sorry about the delay.

[ghost]

I don't mind having a look. I was just wondering what there is to do.

Felipe

On Nov 14, 2011, at 11:14 PM, Patricio Echague wrote:

I'll take this issue. Sorry about the delay.

---

Reply to this email directly or view it on GitHub: https://github.com/rantav/hector/issues/180#issuecomment-2737541