## Membership associations: event registration using Django

### Summary  
A event registration blueprint for membership associations built with Django on Ample.  
Domain schema:  
- **course_groups** (chapter_or_program, start_at, end_at): chapters and programs as groups;  
- **memberships** (course_group_id, member_email, tier, role, renewed_at): members and roles;  
- **sessions** (course_group_id, starts_at, title, venue): meetings and events;  
- **materials** (course_group_id, title, object_key, visibility): member resources;  
- **events** (seq, record_type, record_id, kind, at): application-owned history written in the same transaction.

Public information: about, chapters and benefits, public events, join information.  
Kept out of scope until handling is reviewed: member directory details, dues, and payment records.  
Member directories are personal data; only public events and member-authorized resources are modeled.  
Technical basis verified on Django: an optimistic version check and an event row written in the same transaction, a stale update rejected, and a history query over the application-owned events (history=2 conflict=rejected).

### Representative Queries  
- Membership associations: event registration using Django  
- Where can I host Membership associations: Event registration built with Django?  
- I need a genuinely specialized event registration workflow covering membership tiers, event eligibility and shared resources.

### Workflow Steps  
1. **Model the membership associations domain**  
   Create the tables course_groups, memberships, sessions, materials, events. Chapters and programs as groups lives in course_groups; keep the sensitive classes (member directory details, dues and payment records) out of this schema.  
2. **Model sessions** with capacity and registrations with status.  
3. **Register transactionally** with a capacity check and an event per registration.  
4. **Reject stale concurrent updates.**  
5. **Deploy**: Run the synchronous deploy once and read the result. Re-running with no change is a no-op.  
   Command: `ample deploy . --name --public --start "python3 run.py" --env S3_ENDPOINT=... --env S3_REGION=... --env S3_BUCKET=... --env S3_ACCESS_KEY_ID=... --env S3_SECRET_ACCESS_KEY=...`  
6. **Verify**: Run the pattern self-test(s) from the example (/p/transactional-workflows) and your own acceptance checks for the membership associations workflow.  
   Command: `ample logs --kind build`

### Prerequisites  
- A Django project (pip install into .ample/python from requirements.txt, then waitress serving project.wsgi from run.py reading PORT on the python-3.12 template)  
- A PostgreSQL driver reading DATABASE_URL (auto-provisioned when omitted)  
- Bucket credentials from `ample bucket create` passed as encrypted S3_* environment variables  
- A review of which membership associations data classes may be handled at all; this blueprint models public information only

### Limitations  
- The technical basis (transactional workflows on Django) was verified with the pattern fixture; the membership associations schema and workflow are an original design for this blueprint and were not executed as a separate application.  
- No health, financial, privacy or other compliance claim is made. Member directories are personal data; only public events and member-authorized resources are modeled.  
- Public content and synthetic examples only until actual data-handling requirements have been reviewed.  
- Verified on the python-3.12 template at s-1vcpu-1gb; region, request-duration limits and other sizes are unknown or unverified.  
- Managed PostgreSQL 16 only; extensions, connection limits and backup or restore procedures are not verified.  
- PutObject and GetObject with path-style addressing are verified; other S3 operations and CDN cache rules are not.