From users-return-12-archive-asf-public=cust-asf.ponee.io@unomi.apache.org Fri Oct 12 17:40:22 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id EBD0A180660 for ; Fri, 12 Oct 2018 17:40:21 +0200 (CEST) Received: (qmail 10877 invoked by uid 500); 12 Oct 2018 15:40:21 -0000 Mailing-List: contact users-help@unomi.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@unomi.apache.org Delivered-To: mailing list users@unomi.apache.org Received: (qmail 10863 invoked by uid 99); 12 Oct 2018 15:40:21 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Oct 2018 15:40:21 +0000 Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 16F9DE1C for ; Fri, 12 Oct 2018 15:40:20 +0000 (UTC) Received: by mail-ot1-f50.google.com with SMTP id w67so12774019ota.7 for ; Fri, 12 Oct 2018 08:40:20 -0700 (PDT) X-Gm-Message-State: ABuFfogjHuw2FRFt64o+nkcA2O5wLTDUipFeVuw/Nv/e1hkzqXTqv+gr P13/KiWuLa+3AyoKi5B1CJFfFsotcMZOVM2zgUcIJQ== X-Google-Smtp-Source: ACcGV625jC+r3RlhwwZcystfVJG6fqjNDOFP0gY1vZfXORptfZ12RgR6xGG6sr8ZnAl7saQsnV+FvEIPaClxSeLiFJM= X-Received: by 2002:a9d:4590:: with SMTP id x16mr4383098ote.258.1539358819533; Fri, 12 Oct 2018 08:40:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Serge Huber Date: Fri, 12 Oct 2018 17:40:08 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Centralizing Customer Data in Unomi To: users@unomi.apache.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Michael, Yes that what it means. You could extend MetadataItem as you have correctly guessed. Basically the rule of thumb is to store as much as possible in the Profile because that were you can really leverage all the power of the Segmentation and other queries that you could do in Unomi. But if you need to tie profiles to entities that don't have a direct 1-to-1 relationship (as is the case for households), you might have to define these new entities as Items. Regards, Serge... On Thu, Oct 11, 2018 at 7:59 PM Michael Ghen wrote: > > Thanks Serge,. > > re: Or by developing a plugin you could also define your own object type = in ElasticSearch to model a household. > > This is what Extending Unomi with Plugins in the docs talks about, right?= This was kind of what I was thinking of was creating a "profile" for each = person and link them to a "household." Household would be a type I could ha= ve to create as an extension, right? I would extend MetadataItem in Java? > > We also have other entities that are tied to households, like expenses. F= or these kinds of entities, is there a critera for what should be implement= ed as a plugin vs. what should be added into properties? > > On Thu, Oct 11, 2018 at 12:01 PM Serge Huber wrote: >> >> Hello Mike, >> >> There are different ways you could do this but what comes to mind >> first would be to have a new "houseHoldID" property for profiles and >> storing in their the same ID for all members of the same household. >> The ID could be for example a lastname but would have to be designed >> to be pretty unique to avoid conflicts. >> >> Or you could store an address and simply search for all profiles >> living at the same address. >> >> Or by developing a plugin you could also define your own object type >> in ElasticSearch to model a household. This is simpler than you think, >> simply define a Java object class that inherits from MetadataItem and >> use the persistence service to save and load it. You could then store >> a reference to this household id in profiles. >> >> I hope this helps, >> Regards, >> Serge... >> >> >> On Thu, Oct 11, 2018 at 4:00 PM Michael Ghen wrote: >> > >> > Hello, >> > >> > I have been exploring Unomi for a few weeks now and think it could hel= p us centralize our customer data. I have a question about what the best wa= y to map our customer data model to Unomi. I understand its elasticsearch o= n the backend which isn't a system I have a lot of experience, so I'm hopin= g for some recommendations. >> > >> > The information we have about our customers includes their household c= omposition. For example, a customer is a 65 y/o male living with their wife= , we have all the personal information for both people in the household. An= other example is a 45 y/o female living with three children, we have all th= eir information as well. We provide services to all the people in the hous= ehold but there is always a "primary member" identified. >> > >> > My question is, how would these customers be modeled in Unomi? I just = wondering what the best way to store the full households information would = be given how Unomi works. We want to have actions and rules based on househ= old attributes like "number of children" or "number of people over 65." Whe= n we perform actions, we need the name and birthdate of all the people in t= he household. >> > >> > Right now, we do all of this in Ruby on Rails and use a MySQL database= . >> > >> > Respectfully, >> > >> > Mike >> >