CQL equivalent in HOM

49 views
Skip to first unread message

atig

unread,
Oct 25, 2011, 7:11:56 PM10/25/11
to hector-users
How would I implement a CQL query like Select * from User using the
EntityManager of HOM?
Is there anything CQL equivalent?

coder18

unread,
Oct 27, 2011, 2:58:56 PM10/27/11
to hector-users
This is must have to HOM. HOM needs CQL, so that it makes sense to use
HOM, otherwise it's just crippled version of hector.

Nate McCall

unread,
Oct 27, 2011, 3:06:56 PM10/27/11
to hector...@googlegroups.com
If this is something you need, please feel free to create an issue
with a feature request or, even better: fork, build it out, and submit
a pull request. Either way, a lot of folks seem to find the current
functionality valuable.

B. Todd Burruss

unread,
Oct 27, 2011, 7:21:25 PM10/27/11
to hector...@googlegroups.com
this falls into the category of wanting to map multiple objects with a
single call to HOM. so regardless if using CQL or some other
mechanism, how can we map many objects at once ... similar to Issue
#276

coder18

unread,
Oct 28, 2011, 3:31:39 AM10/28/11
to hector-users
If I have understood correctly, HOM is just using Hectors interface to
create ORM to Hector? When Hector returns rows, HOM returns model
objects (which are mapped from rows to objects)? If Hector has CQL, it
should be trivial to add HOM to support it?

On 28 loka, 02:21, "B. Todd Burruss" <bto...@gmail.com> wrote:
> this falls into the category of wanting to map multiple objects with a
> single call to HOM.  so regardless if using CQL or some other
> mechanism, how can we map many objects at once ... similar to Issue
> #276
>
>
>
>
>
>
>
> On Thu, Oct 27, 2011 at 12:06 PM, Nate McCall <n...@datastax.com> wrote:
> > If this is something you need, please feel free to create an issue
> > with a feature request or, even better: fork, build it out, and submit
> > a pull request. Either way, a lot of folks seem to find the current
> > functionality valuable.
>

atig

unread,
Oct 28, 2011, 2:00:59 PM10/28/11
to hector-users
I agree with coder18 that, without it, HOM is sligthly at a
disadvantage.
It works brilliantly for working with single objects but in reality we
do need multiple objects.

Can we not have something like List<T> resultRows to return all
objects?
Something similar to Criteria API in Hibernate

B. Todd Burruss

unread,
Oct 28, 2011, 2:31:06 PM10/28/11
to hector...@googlegroups.com
For the object mapping part, you can use EntityManager.load and pass
in the ColumnSlice and let HOM handle all
the mapping.

atig

unread,
Oct 28, 2011, 3:02:57 PM10/28/11
to hector-users
Tried it I get the following exception

Exception in thread "main" java.lang.RuntimeException:
java.lang.IllegalArgumentException: Object type, class
com.test.cass.data.model.House, does not have a property named, KEY.
either add a setter for this property or use @AnonymousPropertyHandler
to annotate a method for handling anonymous properties
at
me.prettyprint.hom.HectorObjectMapper.createObject(HectorObjectMapper.java:
273)
at
me.prettyprint.hom.EntityManagerImpl.load(EntityManagerImpl.java:
158)
at
com.test.cass.data.dao.impl.DataModelTest.usingHectorAndHomForRead(DataModelTest.java:
86)
at
com.test.cass.data.dao.impl.DataModelTest.main(DataModelTest.java:
64)
When I save the object using EM.save the @Id is saved as the KEY
column. That IS the expected behaviour isn't it?
But when I tried EM.load with ColumnSlice, an exception is thrown
because there is no 'KEY'column in my House object.
This is the House object

public class House {
@Id
private long id;
...

atig

unread,
Oct 28, 2011, 5:01:21 PM10/28/11
to hector-users
I haven't looked at the inner workings yet, but here's something
interesting. If I use a MutligetSliceQuery as follows and then use
EM.load with ColumnSlice everything works great.

MultigetSliceQuery<Long, String, byte[]> query =
HFactory.createMultigetSliceQuery(keyspace, longSerializer,
stringSerializer, byteArraySerializer);
query.setColumnFamily("House");
query.setKeys(1L,2L,3L,5L,6L,47L,437L,34L,26L,23L,8L,8956L,3467L,
2346L,623L,85L);
query.setRange("", "", false, 8);
QueryResult<Rows<Long,String, byte[]>> result = query.execute();
EntityManagerImpl em = new EntityManagerImpl(keyspace,
"com.test.cass");
List<House> houses = new ArrayList<House>(result.get().getCount());
for (Row row : result.get()) {
House house = em.load(House.class, row.getKey(),
row.getColumnSlice());
houses.add(house);
}

But if I use a CQL query such as Select * from House

CqlQuery<Long, String, byte[]> cqlQuery = new CqlQuery<Long, String,
byte[]>(keyspace, longSerializer, stringSerializer,
byteArraySerializer);
cqlQuery.setQuery("select * from House");
QueryResult<CqlRows<Long, String, byte[]>> resultCql =
cqlQuery.execute();
CqlRows<Long, String, byte[]> result = resultCql.get();
List<Formation> formations = new ArrayList<Formation>(10000);
EntityManagerImpl em = new EntityManagerImpl(keyspace,
"com.test.cass");
for (Row row : result.getList()) {
House house = em.load(House.class, row.getKey(),
row.getColumnSlice());
houses.add(house);
}
I get the above exception.

java.lang.IllegalArgumentException: Object type, class
com.test.cass.data.model.House, does not have a property named, KEY.
either add a setter for this property or use @AnonymousPropertyHandler
to annotate a method for handling anonymous properties
at
me.prettyprint.hom.HectorObjectMapper.createObject(HectorObjectMapper.java:
273)
...

B. Todd Burruss

unread,
Oct 28, 2011, 6:08:30 PM10/28/11
to hector...@googlegroups.com, hecto...@googlegroups.com
[adding hector-dev for this]

@Id does not persist the ID field as a column, it becomes the row key.
the exception you see means that there is a column name, KEY, in the
result slice that doesn't map to a POJO property - and you do not have
an anonymous property handler.

i am not familiar with CQL details, so maybe it is adding a field,
KEY, to the query result?

can anyone familiar with CQL in hector comment?

Nate McCall

unread,
Oct 28, 2011, 6:09:37 PM10/28/11
to hecto...@googlegroups.com, hector...@googlegroups.com
It is in fact adding a KEY field to result to get around semantical mis-match.

B. Todd Burruss

unread,
Oct 28, 2011, 6:15:40 PM10/28/11
to hecto...@googlegroups.com, hector...@googlegroups.com
how is column name collision avoided? HOM can't assume that if the
column name, KEY, is seen to disregard it.

(i'll take a look at the code)

Nate McCall

unread,
Oct 28, 2011, 6:18:05 PM10/28/11
to hecto...@googlegroups.com, hector...@googlegroups.com
See QueryResult in the thrift API and CqlQuery/Test in Hector source
tree. It's kinda screwy but it makes sense.

B. Todd Burruss

unread,
Oct 28, 2011, 6:57:37 PM10/28/11
to hecto...@googlegroups.com, hector...@googlegroups.com
it is screwy ... so the only thing i see different between CQL's KEY
column name and a user generated KEY column name is the timestamp (and
the value of course). CQL's KEY column has a timestamp of -1. so
when using CQL the user must manually disregard CQL's KEY column? is
this correct?

(i'm trying to come up to speed with CQL)

atig

unread,
Oct 31, 2011, 7:07:27 AM10/31/11
to hector-users
Cool. So how do I resolve this?

On Oct 28, 10:57 pm, "B. Todd Burruss" <bto...@gmail.com> wrote:
> it is screwy ... so the only thing i see different between CQL's KEY
> column name and a user generated KEY column name is the timestamp (and
> the value of course).  CQL's KEY column has a timestamp of -1.  so
> when using CQL the user must manually disregard CQL's KEY column?  is
> this correct?
>
> (i'm trying to come up to speed with CQL)
>
>
>
>
>
>
>
> On Fri, Oct 28, 2011 at 3:18 PM, Nate McCall <n...@datastax.com> wrote:
> > See QueryResult in the thrift API and CqlQuery/Test in Hector source
> > tree. It's kinda screwy but it makes sense.
>
> > On Fri, Oct 28, 2011 at 5:15 PM, B. Todd Burruss <bto...@gmail.com> wrote:
> >> how is column name collision avoided?  HOM can't assume that if the
> >> column name, KEY, is seen to disregard it.
>
> >> (i'll take a look at the code)
>
> >> On Fri, Oct 28, 2011 at 3:09 PM, Nate McCall <n...@datastax.com> wrote:
> >>> It is in fact adding a KEY field to result to get around semantical mis-match.
>
> >>> On Fri, Oct 28, 2011 at 5:08 PM, B. Todd Burruss <bto...@gmail.com> wrote:
> >>>> [adding hector-dev for this]
>
> >>>> @Id does not persist the ID field as a column, it becomes the row key.
> >>>>  the exception you see means that there is a column name, KEY, in the
> >>>> result slice that doesn't map to a POJO property - and you do not have
> >>>> an anonymous property handler.
>
> >>>> i am not familiar with CQL details, so maybe it is adding a field,
> >>>> KEY, to the query result?
>
> >>>> can anyone familiar with CQL in hector comment?
>

B. Todd Burruss

unread,
Nov 1, 2011, 7:15:36 PM11/1/11
to hector...@googlegroups.com
added issue-320. this will be fixed in hector-core, at which time HOM
will work as you expect.

atig

unread,
Nov 4, 2011, 1:37:17 AM11/4/11
to hector-users
Thanks. I will watch for the fix, I was wondering if there was a way
to fix this in the meanwhile?

I have seen couple of commits from Nate so was wondering if I can find
(look at) a fix in the current master?

Nate McCall

unread,
Nov 4, 2011, 11:33:12 AM11/4/11
to hector...@googlegroups.com
Yep - was in as of Wednesday (apologies - forgot to close the issue).
https://github.com/rantav/hector/issues/320

atig

unread,
Nov 4, 2011, 7:07:28 PM11/4/11
to hector-users
Thanks. The inevitable question; when are you planning to release a
patch for the current version.

On Nov 4, 3:33 pm, Nate McCall <n...@datastax.com> wrote:
> Yep - was in as of Wednesday (apologies - forgot to close the issue).https://github.com/rantav/hector/issues/320

atig

unread,
Nov 4, 2011, 7:46:17 PM11/4/11
to hector-users
Also, I just looked at the tests, wouldn't you want to
supressKeyColumn as a default behaviour?
I also read the blurb on the issue so I have the same query as B.
Todd.

Nate McCall

unread,
Nov 4, 2011, 9:51:38 PM11/4/11
to hector...@googlegroups.com
Nope - no interest in straying from the default behavior of the API -
good, bad or ugly. When we've tried this a few times in the past, it's
always gone bad.
Reply all
Reply to author
Forward
0 new messages