sorry Lawrence. I re-read my post and consider it incomplete, out-of- context, and generally snotty ;). I'll retract it, as I wrote it too quickly.
The point I was trying to make is that I see so many using the now classical "three-tier" architecture in a way in that the app processes are the master and the DB process is a secondary "brain-dead" lookup. This is, I think, a solid ideal and an original goal of the three-tier architecture. But most web app frameworks don't really make this solution achievable. People end up using the app tier in very inefficient ways instead of leaning on a more solid RDB and making good use of relational integrity. If the ORM assumes the app dev will follow proper RDB rules, the app processes should never be in a position to have to decide if data is good or not. If its not in the RDB, its not good and a by-product of the app tier implementation (multiple dumb, non-communicating app processes); all integrity exists through the "shared DB". This is why I consider "shared nothing" architecture a misnomer. Things are shared, all through the RDB. That's the point of integrity, not the app layer. So we actually may be in perfect agreement. I just made my first post too quickly. thanks, Jon On Oct 30, 5:50 pm, Lawrence Pit <[EMAIL PROTECTED]> wrote: > Jon, > > Please explain. There's nothing improper about it imo. Relational > integrity remains totally intact in the db at all times in the examples > I gave. > > Lawrence > > > Lawrence, > > In my religion, your examples of these exceptional cases are caused by > > improper RDB relational integrity. ;) > > Jon > > > On Oct 30, 2:39 pm, Lawrence Pit <[EMAIL PROTECTED]> wrote: > > >>> That was my decision. It's a religious thing I don't expect everyone > >>> to agree with. I'm firmly in the "exceptions should not be used for > >>> flow-control" camp. ;-) > > >>> The exception being that a get for a specific id should always raise > >>> because it's an exceptional situation not to find the object then. > > >> Imho a get for a specific id should also not raise an exception. Just a > >> nil please. > > >> Two areas where not finding a result for a specific id is not that > >> exceptional: > > >> - even though you have the reference key value, a paranoid bit might > >> prevent you from seeing the actual record > > >> - due to lazy loading strategies internally to dm, dm might have a > >> reference to a record that existed at the time a collection of ids was > >> loaded for an association, but as soon as dm iterates over the > >> collection later on, one of the referenced records may have been deleted > >> by another user or process. Instead of failing for the whole iteration > >> process I'd continue and return a collection where one of its members is > >> nil. > > >> Lawrence --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
