Hi,
CREATE TABLE sensor_data (
sensor_id text,
date text,
data_time_stamp timestamp,
reading int,
PRIMARY KEY ( (sensor_id, date),
data_time_stamp) );
Yes, you can create a POJO for this and map exactly with one row as a POJO
object.
Please have a look at:
https://github.com/impetus-opensource/Kundera/wiki/Using-Compound-keys-with-Kundera
There are users built production system using Kundera, please refer :
https://github.com/impetus-opensource/Kundera/wiki/Kundera-in-Production-Deployments
I am working as a core commitor in Kundera, please do let me know if you
have any query.
Sincerely,
-Vivek
On Wed, Oct 23, 2013 at 10:41 PM, Les Hartzman <[email protected]> wrote:
> Hi Vivek,
>
> What I'm looking for are a couple of things as I'm gaining an
> understanding of Cassandra. With wide rows and time series data, how do you
> (or can you) handle this data in an ORM manner? Now I understand that with
> CQL3, doing a "select * from time_series_data" will return the data as
> multiple rows. So does handling this data equal the way you would deal with
> any mapping of objects to results in a relational manner? Would you still
> use a JPA approach or is there a Cassandra/CQL3-specific way of interacting
> with the database?
>
> I expect to use a compound key for partitioning/clustering. For example
> I'm planning on creating a table as follows:
> CREATE TABLE sensor_data (
> sensor_id text,
> date text,
> data_time_stamp timestamp,
> reading int,
> PRIMARY KEY ( (sensor_id, date),
> data_time_stamp) );
> The 'date' field will be day-specific so that for each day there will be a
> new row created.
>
> So will I be able to define a POJO, SensorData, with the fields show above
> and basically process each 'row' returned by CQL as another SensorData
> object?
>
> Thanks.
>
> Les
>
>
>
> On Wed, Oct 23, 2013 at 1:22 AM, Vivek Mishra <[email protected]>wrote:
>
>> Can Kundera work with wide rows in an ORM manner?
>>
>> What specifically you looking for? Composite column based implementation
>> can be built using Kundera.
>> With Recent CQL3 developments, Kundera supports most of these. I think
>> POJO needs to be aware of number of fields needs to be persisted(Same as
>> CQL3)
>>
>> -Vivek
>>
>>
>> On Wed, Oct 23, 2013 at 12:48 AM, Les Hartzman <[email protected]>wrote:
>>
>>> As I'm becoming more familiar with Cassandra I'm still trying to shift
>>> my thinking from relational to NoSQL.
>>>
>>> Can Kundera work with wide rows in an ORM manner? In other words, can
>>> you actually design a POJO that fits the standard recipe for JPA usage?
>>> Would the queries return collections of the POJO to handle wide row data?
>>>
>>> I had considered using Spring and JPA for Cassandra, but it appears that
>>> other than basic configuration issues for Cassandra, to use Spring and JPA
>>> on a Cassandra database seems like an effort in futility if Cassandra is
>>> used as a NoSQL database instead of mimicking an RDBMS solution.
>>>
>>> If anyone can shed any light on this, I'd appreciate it.
>>>
>>> Thanks.
>>>
>>> Les
>>>
>>>
>>
>