Object- Relational Persistence in Smalltalk

1,259 views

Published on

Object- Relational Persistence in Smalltalk
(ESUG 2004, Koethen)

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,259
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Object- Relational Persistence in Smalltalk

  1. 1. Object- Relational Persistence in Smalltalk Alan Knight (knight@acm.org) Cincom Systems of Canada
  2. 2. What is GLORP Generic Lightweight Object-Relational Persistence Open-source library for O/R mapping LGPL(S) Camp Smalltalk project Sponsored by The Object People (2000) Portable Planned as one part of major overhaul of Object Lens
  3. 3. Motivating Example Cincom internal application Widely used internally and by customers Critical Relatively simple model 19 tables somewhere between 12 and 46 domain classes Client-server (although server functionality desirable)
  4. 4. Issues Schema changes extremely difficult "Interesting" schema Performance critical Some operations over very high-latency links Significant amounts of data Versioning schema, heavily linked data Must support multiple databases Demo
  5. 5. Relationship Example (aDescriptor newMapping: ToManyMapping) attributeName: #methods; referenceClass: StoreMethodInPackage; useLinkTable; join: (Join from: primaryKeyField to: methodsTable packageRefField). methodMapping query alsoFetch: [:each | each definition]. methodMapping query expectedRows: 1000. Note that Join defines read, write, and join. Note optimizations
  6. 6. Packages and Classes In Store, "Package" means one version "Class" means ClassDefinition Entities in database are not like traditional in- memory entities e.g. what package contains this method Introduce additional entities StoreVersionlessPackage StoreMethodInPackage (etc) StoreClassExtension Clearer domain model, ability to express querie
  7. 7. Demo 2 Querying UI Replicating Browsing Optimizations Caching
  8. 8. Writing Unit of Work Purely transactional No explicit writes In-memory rollback Automatic insert/update Automatic write order/referential integrity Mostly automatic database transactions Optimized
  9. 9. Notable Technical Points Object-level rollback in Unit of Work RowMaps and write optimization Block to expression conversion Joins declarative - defines the table relationship simple handles all uses
  10. 10. Acknowledgements The Object People Cincom All the contributors and users of GLORP
  11. 11. References GLORP http://www.glorp.org http://glorp.sourceforge.net General Ambler: Object Primer, http://www.agiledata.com (good emphasis on importance of both worlds) Fowler: Patterns of Enterprise Application Architecture (good patterns, once you ignore the non-domain model stuff) Fabian Pascal: Practical Issues in Database Management (pure relational extremist) ROE - Avi Bryant Gemstone
  12. 12.  2004 Cincom Systems, Inc. All Rights Reserved CINCOM and The Smart Choice are trademarks or registered trademarks of Cincom Systems, Inc All other trademarks belong to their respective companies.
  13. 13. Reading non-Object Data Reading pure data, ordering query := Query readManyOf: StorePackage. Aggregate functions query orderBy: [:each | each name]. query retrieve: [:each | each name distinct]. query retrieve: [:each | each primaryKey max]. Retrieving pieces of objects query retrieve: [:each | each id]. query retrieve: [:each | each name]. query retrieve: [:each | each address] (changing contexts) Note: All internal queries generated by user-accessible mechanisms.
  14. 14. Change Hats: VisualWorks Next-generation database frameworks, inputs VisualWorks Object Lens Strong in many respects, but very dated Client-server orientation Object Studio POF Very strong modelling GLORP Open-source Extremely flexible mapping layer SQLWorks Good server orientation *very* high-performance Goal: Synthesize the best of all these
  15. 15. Core Issues Object identity vs primary keys Pointers vs. foreign keys Networks of objects vs. rows Queries vs. traversing relationships Encapsulation vs. program independence nil is not null The role of the application
  16. 16. Incidental Issues Keys: natural vs. generated Integrity constraints Inheritance Mismatched schemas Agility
  17. 17. General Database/Multi-User Issues Scaling When to read data? What do queries look like? Performance, performance, performance Locking Caching, refreshing, keeping data in sync Transaction semantics (knowing which transaction to use) Transaction lengths Multi-user within an image?
  18. 18. Approaches Metadata or code generation Associating objects with transactions SQL, OO query language, objects as queries, special syntax Explicit or automatic writes Marking objects dirty When to take objects out of cache Different framework architectures (e.g. brokers, subclassing)
  19. 19. GLORP Licensing LGPL (Lesser GNU Public License) Can be used as a library, does not affect linked code Modifications must be released under the same license But… LGPL’s terminology very difficult to interpret with respect to Smalltalk. Approach Include a clarification with GLORP, specifying a sensible Smalltalk interpretation of the license Copyright held by the authors/not assigned Counsel: Lawrence Rosen (also general counsel of OSI)

×