| *** pvaneck has quit IRC | 00:44 | |
| *** davidlenwell has quit IRC | 00:53 | |
| *** davidlenwell has joined #refstack | 01:05 | |
| *** ChanServ sets mode: +o davidlenwell | 01:05 | |
| *** Deng has joined #refstack | 03:21 | |
| *** andrey-mp has joined #refstack | 05:45 | |
| *** andrey-mp has quit IRC | 06:45 | |
| *** markvoelker has quit IRC | 07:34 | |
| *** andrey-mp has joined #refstack | 08:09 | |
| *** rmart04 has joined #refstack | 08:20 | |
| *** markvoelker has joined #refstack | 08:34 | |
| *** andrey-mp has quit IRC | 08:35 | |
| *** markvoelker has quit IRC | 08:39 | |
| *** markvoelker has joined #refstack | 09:36 | |
| *** markvoelker has quit IRC | 09:40 | |
| *** andrey-mp has joined #refstack | 09:41 | |
| *** markvoelker has joined #refstack | 11:37 | |
| *** markvoelker has quit IRC | 11:42 | |
| *** markvoelker has joined #refstack | 12:35 | |
| *** edmondsw has joined #refstack | 13:14 | |
| *** Deng has quit IRC | 13:30 | |
| *** designbybeck_ has joined #refstack | 13:43 | |
| *** rmart04 has quit IRC | 15:13 | |
| *** andrey-mp has quit IRC | 15:33 | |
| *** hockeynut has joined #refstack | 15:54 | |
| *** andrey-mp has joined #refstack | 17:07 | |
| andrey-mp | catherineD: i'm here | 17:18 |
|---|---|---|
| catherineD | andrey-mp: thank you very much! | 17:19 |
| catherineD | since I think we can have interactive discussion here about the comment you put on the alternative section in https://review.openstack.org/#/c/353903/ | 17:20 |
| andrey-mp | sure | 17:20 |
| andrey-mp | but my comments about alternative section can be ommited ) | 17:20 |
| andrey-mp | it was just a thoughts | 17:20 |
| catherineD | andrey-mp: I want to consider if it make sense .. | 17:21 |
| catherineD | also in case I miss some thing | 17:21 |
| catherineD | that you think of | 17:21 |
| andrey-mp | i dislike my first variant - because i dislike component primary keys | 17:22 |
| catherineD | so for both examples the design only have one table ( product table) right? | 17:22 |
| andrey-mp | yes | 17:22 |
| catherineD | on the second example is "product MOS" just the name of the product? | 17:23 |
| andrey-mp | just adding 'version' column to product table (this breaks 2NF - second normal form of DB) | 17:23 |
| andrey-mp | yes, it's a name | 17:23 |
| catherineD | so in the second table product_id will be unique primary key created by the system .. | 17:25 |
| *** pvaneck has joined #refstack | 17:25 | |
| catherineD | product name and version will be user input .. | 17:25 |
| andrey-mp | you mean variant with two tables? | 17:26 |
| catherineD | No, I am still trying to understand your example 2 ... in which the product table will have column: product_id, version, name, ...... | 17:27 |
| catherineD | and product_id is the id that created automatically whenever a product is created .. | 17:28 |
| catherineD | version and name are user input when create the product ... | 17:28 |
| andrey-mp | yes. this variant assumes that each version it is a new product | 17:29 |
| catherineD | yea that is not the model that OSF ... in their model there is only one product with many versions | 17:29 |
| catherineD | yes the model in example 2 is as you said each version is a new product | 17:30 |
| andrey-mp | they treat product as a object with some name and this product has versions or not | 17:31 |
| catherineD | I can add your example 2 to the spec to log that we thought about this model .. but it does not reflect the 1 product to many versions model | 17:31 |
| catherineD | correct | 17:31 |
| andrey-mp | it can reflect ) | 17:32 |
| andrey-mp | we define how we will build our DB and our API | 17:32 |
| catherineD | this is what I missed pls tell me how ... | 17:32 |
| andrey-mp | and due to DB layer is hidden from user - we can do anything | 17:32 |
| catherineD | the reason I do not see it reflect is ... | 17:33 |
| andrey-mp | for product with two version DB will have two items | 17:33 |
| andrey-mp | and these two items can have similar names or not, can have different cpid (for example) | 17:33 |
| catherineD | how would the two item in db reflect one product with 2 version in the marketplace | 17:34 |
| catherineD | especially the two items with similar name or not | 17:34 |
| andrey-mp | how it implemented now? we don't have imlement that relates product to marketplace | 17:35 |
| openstackgerrit | Merged openstack/refstack-client: Add specs hierarchy into refstack-client https://review.openstack.org/349133 | 17:35 |
| catherineD | How do people know that this is one product | 17:35 |
| catherineD | andrey-mp: the plan is once we have this implemented | 17:36 |
| andrey-mp | in such vision it is not one product - this is two products. | 17:36 |
| catherineD | the test link on the marketplace will be a link on the RefStack website | 17:37 |
| catherineD | let take one example in the marketplace for our discussion | 17:37 |
| andrey-mp | they still don't have versions as I see | 17:38 |
| *** hockeynut has quit IRC | 17:38 | |
| andrey-mp | Mirantis OpenStack (MOS) has versions 6.1 7.0 8.0 9.0 | 17:38 |
| andrey-mp | all these versions still exist | 17:38 |
| catherineD | tell me what is the name on the marketplace ? | 17:39 |
| andrey-mp | Mirantis OpenStack | 17:39 |
| catherineD | ok | 17:39 |
| andrey-mp | this is - https://www.openstack.org/marketplace/distros/distribution/mirantis/mirantis-openstack | 17:40 |
| catherineD | do you see the tested green box | 17:40 |
| catherineD | and the see fill results[+] link? | 17:41 |
| andrey-mp | sure ) | 17:41 |
| andrey-mp | but my question still exists - which version eas tested? | 17:41 |
| catherineD | currently when you click the full result link it just show a standard table | 17:42 |
| catherineD | in the future this will show one or mor links on the refstack page ... | 17:42 |
| catherineD | each link of the refstack page will be tied to a product version | 17:43 |
| catherineD | so there will be more than one link | 17:43 |
| andrey-mp | so it is a main use case for this feature in RefStack - support marketplace model | 17:44 |
| catherineD | yes | 17:44 |
| catherineD | the product name will always be Mirantis OpenStack | 17:45 |
| catherineD | For your example 2 model ... since name is user input ... we can not guarantee that the user will inout the same names for all versions of the same product | 17:46 |
| andrey-mp | in my examples i tried to model DB by another way | 17:47 |
| andrey-mp | your definition is related to UI - for example, if user wants to add version to product, we forbid to define a name and just a copy DB item | 17:48 |
| catherineD | the only reason why I see this model does not work because we have to rely on user input for to enforce the same names for the different entries | 17:48 |
| catherineD | andrey-mp: there is no copy off db item if we use the two table (product, version ) model | 17:49 |
| catherineD | product would just created once in the product table | 17:49 |
| andrey-mp | another example of breaking 2NF (https://en.wikipedia.org/wiki/Second_normal_form) - is to store products and vendors in one huge table ) | 17:49 |
| andrey-mp | sure | 17:49 |
| catherineD | version can be created many times | 17:50 |
| andrey-mp | sure, I understand you | 17:50 |
| andrey-mp | this is all about terminology - can we treat different versions of one product as different product in our DB or it's better to be similar to marketplace | 17:51 |
| catherineD | the 1 to many relation ship is usually model in database with 2 tables ... organization to product is another example of 1 org to many product relationship | 17:52 |
| catherineD | andrey-mp: exactly | 17:52 |
| catherineD | if OSF defines each version of a product is a product then all we need to do is to add a vesion column | 17:53 |
| catherineD | but they define a product is a product that have many versions | 17:53 |
| andrey-mp | I agree that in this case it's simplier to be as OSF | 17:53 |
| catherineD | it is more complicated but using 2 table it works for a 1 to 1 or 1 to n relationship ... | 17:55 |
| catherineD | the reason I what to have a unique constrain on (product_id, version) is to prevent some one to create same versions for a product | 17:57 |
| andrey-mp | catherineD: I told you many about second normal form. it is not complicated. it is about how to architect DB model. | 17:57 |
| andrey-mp | about product-version constraint. I think that it's not good to use 'user input string' as part of key. because user can input one term with many ways. | 17:58 |
| catherineD | 2NF for in the version table? | 17:58 |
| catherineD | if user put one term in many ways then it is user issue in my mind ... and that would reflect may versions | 17:59 |
| andrey-mp | for product table and version table | 17:59 |
| catherineD | how do you do that for version table? | 18:00 |
| andrey-mp | so in case when user can input one term in many ways then this constraint doesn't work. this is not good - 'it works sometimes' | 18:01 |
| catherineD | if user input | 18:01 |
| andrey-mp | let's stop talking about tables ) let's alternative section will be empty. I agree that two tables is better now. | 18:01 |
| catherineD | andrey-mp: I think it is a good idea to put what you indicate in the alterantive section .. to document that we have think about this | 18:02 |
| catherineD | we actually do a complete analysis of all the options | 18:03 |
| andrey-mp | ok, I am not sure that I understood your last question | 18:03 |
| catherineD | so now we agree that we will use the 2 table model ... I want to discuss the contraint | 18:04 |
| catherineD | in the version table | 18:04 |
| andrey-mp | ok | 18:04 |
| catherineD | let me give an example | 18:04 |
| catherineD | here is the situation I would like to avoid | 18:04 |
| catherineD | I would indicate when I am done typing the scenario | 18:05 |
| catherineD | product_id, name, version | 18:05 |
| catherineD | 11111, MOS, 6,1 | 18:05 |
| catherineD | 11111, MOS, 7.0 | 18:06 |
| catherineD | 11111, MOS, 6.1 | 18:06 |
| catherineD | the above is the entries in the version table 1111 is the FK of a product | 18:07 |
| catherineD | sorry let me do this again | 18:07 |
| catherineD | version_id, product_id,name, version_name | 18:08 |
| catherineD | 1001,11111,MOS,6.1 | 18:08 |
| catherineD | 1002,11111,MOS,7.0 | 18:08 |
| catherineD | 1003, 11111, MOS, 6.1 | 18:08 |
| catherineD | so version_id (1001, 1002, 1003) will be used to refer to a product of a particular version ... | 18:09 |
| catherineD | to refer to MOS version 6.1 in this case do we use 1001 or 1003? | 18:10 |
| catherineD | so we need to contraint (product_id, version name) to be unque | 18:10 |
| catherineD | done :-) | 18:10 |
| andrey-mp | what if version item 1003 will have version name 'v6.1' | 18:10 |
| andrey-mp | what item will be used for reffering? | 18:11 |
| catherineD | if V6.1 then the user will have to decide whether he should use 1001 or 1003 for his product | 18:11 |
| andrey-mp | same situation in your example ) | 18:12 |
| catherineD | no | 18:12 |
| catherineD | in my exaplem if the user search for version 6.1 .... it will return 2 item | 18:12 |
| catherineD | in the case where user put v6.1 | 18:12 |
| catherineD | when he search 6.1 or v6.1 it will always return 1 item | 18:13 |
| catherineD | it is up to the user to search the right key | 18:13 |
| catherineD | RefStack has no idea whether 6.1 and v6.1 means the same or different thing | 18:14 |
| andrey-mp | same thing with similar items - user should decide what he needs | 18:14 |
| andrey-mp | he have to remove one item | 18:15 |
| catherineD | but we can help to prevent one of the case | 18:15 |
| catherineD | if we have the constraint the first case with bot 6.1 will never exist | 18:15 |
| catherineD | I agree that we can not prevent the second case | 18:16 |
| andrey-mp | and moreover - we don't have such constraint for products | 18:16 |
| catherineD | which should be contraint in the product? | 18:16 |
| andrey-mp | we we want to help - we can do it at business logic layer | 18:16 |
| andrey-mp | constraint that product_name + vendor_id is an unique | 18:17 |
| catherineD | vendor_id does not exist in the product table | 18:18 |
| catherineD | in the version table | 18:18 |
| catherineD | version_id is always unique | 18:18 |
| catherineD | but product_id+version_name is not necessary if we do not put a contraint in | 18:19 |
| andrey-mp | sorry i don't catch this | 18:19 |
| catherineD | the important info for each row in the version table is version_id, version_name, product_id (FK) | 18:21 |
| catherineD | version_id is always unique ... since it is primary key | 18:21 |
| catherineD | but version_id unique does not mane that the comination of version_name, product_id are unique | 18:22 |
| andrey-mp | yes | 18:22 |
| catherineD | but if we contraint version_name. product_id to be unique .. | 18:23 |
| catherineD | the each version_id can only refer to one product with one unique name | 18:23 |
| andrey-mp | so another similar situiation - product table, fields: organization_id, name. organization_id + name does not have a unique constraint | 18:24 |
| catherineD | andrey-mp: good catch | 18:25 |
| catherineD | without that constraint that means that one organization may have more than one products with the same name | 18:26 |
| catherineD | something we should improve in the product table .. | 18:26 |
| andrey-mp | this additional constraint is an attempt to think for user | 18:26 |
| catherineD | to strengthen the model and help user in a systematic way | 18:27 |
| catherineD | of course it can be done at business or db layer ... | 18:27 |
| catherineD | I think we should log a bug for the contraint of org to product name | 18:28 |
| catherineD | andrey-mp: really good catch | 18:28 |
| andrey-mp | I still think that it is a bad idea ) | 18:29 |
| catherineD | I am not insist on that ... it is one of the thing that is nice to have | 18:30 |
| catherineD | but it would help the confusion down the road | 18:30 |
| catherineD | whatever we do ... I want to make sure that we will meet both OSF and other user's scenario (EC2) | 18:31 |
| catherineD | or at least not breaking other users' scenario | 18:31 |
| catherineD | andrey-mp: I know it is Friday evening ... I really appreciate your time for this discussion | 18:32 |
| andrey-mp | no problem ) | 18:32 |
| catherineD | 9:00 pm your time? | 18:32 |
| andrey-mp | 9:30 | 18:33 |
| catherineD | is it 5 days work schedule just like us SAT and SUN off? | 18:34 |
| andrey-mp | yeah | 18:34 |
| andrey-mp | similar to all other (but Israel) | 18:34 |
| catherineD | some companies here have alternate 5 days 4 days work week | 18:37 |
| catherineD | some companies in Asia with 5.5 days week | 18:37 |
| catherineD | I should let you go ... again thanks so much for your time!!! | 18:38 |
| andrey-mp | ok, bye ) | 18:38 |
| catherineD | bye Have a nice weekend! | 18:39 |
| *** andrey-mp has quit IRC | 19:49 | |
| -openstackstatus- NOTICE: The Gerrit service on review.openstack.org is restarting for a scheduled upgrade, but should return to service momentarily: http://lists.openstack.org/pipermail/openstack-dev/2016-August/101394.html | 20:51 | |
| -openstackstatus- NOTICE: The Mediawiki service at wiki.openstack.org will be offline from 21:00 UTC until approximately 23:00 UTC for a planned upgrade http://lists.openstack.org/pipermail/openstack-dev/2016-August/101395.html | 21:00 | |
| *** ChanServ changes topic to "The Mediawiki service at wiki.openstack.org will be offline from 21:00 UTC until approximately 23:00 UTC for a planned upgrade http://lists.openstack.org/pipermail/openstack-dev/2016-August/101395.html" | 21:00 | |
| *** hockeynut has joined #refstack | 21:11 | |
| *** edmondsw has quit IRC | 21:22 | |
| *** designbybeck_ has quit IRC | 21:42 | |
| *** markvoelker has quit IRC | 22:53 | |
| -openstackstatus- NOTICE: ok https://wiki.openstack.org/ is now running Mediawiki 1.27.0; please let us know in #openstack-infra if anything seems wrong | 23:02 | |
| *** ChanServ changes topic to "ok https://wiki.openstack.org/ is now running Mediawiki 1.27.0; please let us know in #openstack-infra if anything seems wrong" | 23:02 | |
| -openstackstatus- NOTICE: https://wiki.openstack.org/ is now running Mediawiki 1.27.0; please let us know in #openstack-infra if anything seems wrong | 23:08 | |
| *** ChanServ changes topic to "#refstack now we're on storyboard: https://storyboard.openstack.org/#!/project/700" | 23:08 | |
| *** hockeynut has quit IRC | 23:35 | |
| *** markvoelker has joined #refstack | 23:54 | |
| *** markvoelker has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!