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 <lhartz...@gmail.com> 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 <mishra.v...@gmail.com>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 <lhartz...@gmail.com>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
>>>
>>>
>>
>

Reply via email to