Thanks Vivek. I'll look over those links tonight.


On Wed, Oct 23, 2013 at 4:20 PM, Vivek Mishra <mishra.v...@gmail.com> wrote:

> 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