CCS "Basic Storage Areas" spec

Posted by ChUIMonster on 13-Dec-2016 13:16

For those who are not following the CCS forum (or perhaps haven't joined it...)

We're trying to get a spec going to define a baseline set of storage areas that ought to be the absolute minimum for a database in order to cure the "everything gets dumped in the schema area" problem.  Interested parties are invited to join us over at:  https://community.progress.com/products/directions/common_component/f/208/t/27321

You might also find this interesting:

[View:/cfs-file/__key/communityserver-discussions-components-files/26/OE_5F00_Standard_5F00_Storage_5F00_Areas.pptx:320:240]

Executive Summary

This document contains a proposal to the Common Component Standards (CCS) Steering Committee to form a new project team whose goal it is to produce a specification for Basic Storage Areas to define a minimum collection of storage areas for an application using an OpenEdge database


The following sections of the document describe in general terms what the component is, the benefits it provides to application developers, and what the team’s deliverables would be.

Component Description

Explain the purpose and architecture of the component.

The purpose of this specification is to describe the minimum, basic, set of storage areas that should be defined for any application that uses an OpenEdge database and to give a specific recommendation beyond the generic statement that “applications should not store user objects in the schema area”.

Benefits and Use Cases

Explain the benefits and expected use cases for the component.

Currently application partners and other developers have no guidance to help them determine an appropriate set of storage areas for their applications.  The only advice from Progress is that no user objects (tables, indexes or large objects) should be assigned to the schema area.  Yet, by default, the only area available is the schema area and, by default, the schema area is the area that newly created objects are assigned to. 

As a result, nearly all new applications, conversions, upgrades and migrations leave the user objects in the schema area.  All of the advanced features of the OpenEdge database rely upon type 2 storage areas.  The schema area is always a type 1 area and objects in the schema area are, therefore, unable to participate in these advanced features.  (It may not be relevant to the CCS process but a side effect is that revenue opportunities for Progress and partners are thus being squandered.)

An explicit set of recommended minimum storage areas will help partners and developers to easily assign their storage objects to appropriate storage areas.  This, in turn, will position their applications to be able to immediately leverage advanced features of the database without painful post-deployment maintenance (such as dumping and re-loading).

Related / Dependent Common Component Specifications

List all related and dependent specifications. Specifications can be submitted and worked on simultaneously.

None known.

Project Team Requirements

List the expected timeframe and deliverables of the project team for this specification project.

It should be possible to define this specification using a small team (4 to 6 people) in a relatively short time frame – perhaps 60 to 90 days.

The major deliverables of this specification:

  1. Structure file defining the recommended storage areas
  2. White paper describing:
    1. the areas and how they should be used
    2. how to safely extend the areas for advanced uses 
    3. Scripts for converting existing schema-only database definitions to the new spec  

All Replies

Posted by Rob Fitzpatrick on 05-Jan-2017 16:27

Should the link above work for those who have not joined CCS?  If not, how does one join?

Posted by ChUIMonster on 06-Jan-2017 05:32

I guess there is some sort of super-secret security being enforced for the CCS forum.  I cannot imagine why but it would go a long ways towards explaining the lack of posts there.

As to how one gets signed up?  Good question.  Try sending an email to Tom Kincaid.  I think he might know,

Posted by marian.edu on 06-Jan-2017 05:38

No idea why is somehow ‘hidden’… this post of Jean explains a bit the transaction to a more ‘open’ environment :)


https://community.progress.com/community_groups/openedge_general/f/26/t/22324?pi20882=1
 

Marian Edu

Acorn IT 
+40 740 036 212

Posted by James Palmer on 06-Jan-2017 05:39

I think you can request to join the group here: community.progress.com/.../

Posted by ChUIMonster on 06-Jan-2017 05:56

I can understand, and agree with, not wanting to allow submarine IP in the door.  The "secret" part comes from the community at large being unable to see what goes on.  Perhaps a reasonable compromise would be to make the CCS forum viewable to everyone (after all, there are no secrets there)  but not writeable unless a poster has agreed to the terms?

Posted by Rob Fitzpatrick on 06-Jan-2017 08:17

I'm working my way through the application process.  A github ID is a requirement?

Posted by Peter Judge on 06-Jan-2017 08:32

No-ish.
 
The in-process  specs tend to be stored in github  and so you may (depending on team) need one.  Even in those cases, only the team lead may need one. Again, it depends on the team’s process.
 
The final specs are at https://github.com/progress/ccs but that’s public and is writable by the steering committee only (since they publish the final specs).
 

Posted by Rob Fitzpatrick on 06-Jan-2017 08:39

When I hit the "Submit Registration" button i get "Please enter Github Id".  It seems to be a required field.  Perhaps it was intended to be an optional field?

Posted by Tom Kincaid on 06-Jan-2017 11:01

Feels like we should fix that. I will look into it. Are you able to just put any old number / character string to complete the registration? (We can fix later).

Posted by Rob Fitzpatrick on 06-Jan-2017 12:13

Not sure.  I was filling in the form at home so I'll try that later today.  Thanks Tom.

Posted by Edward Sullivan on 06-Jan-2017 12:18

Tom and I connected on this and I'll be getting the form updated so that the GitHub ID is no longer a required field.  Hopefully entering a random string will serve as a workaround in the interim.

Thanks

Ed

Posted by gus bjorklund on 08-Jan-2017 11:18

read the contributor agreements, nda’s, and terms of service documents carefully before you sign up.

personally, i am unable to accept the terms.

Posted by Mike Fechner on 08-Jan-2017 11:26

There is no NDA involved at all!
 

This thread is closed