There was a discussion about the database layout we want to use on irc (nov 11th):  
{{{
20:13 <ryan> one place i think we could start is to take the sf-active database schema
20:13 <ryan> make improvements to it
20:13 <ryan> and just start getting a cak project going
20:13 <yossarian> sounds good
20:13 <yossarian> i assume that sf-active has like a flat inheritance hierarchy, though?
20:13 <ryan> i mean, we might end up with radically different sql
20:13 <yossarian> personally i was thinking we might want to have a database with inheritance, so we don't have a table for articles, a table for events, a 
                  table for XXXX
20:13 <yossarian> instead have one content table
20:14 <yossarian> with a "type" column
20:14 <ryan> interesting... if we can figure that out, lets put that change into the sfa swl
20:14 <yossarian> and do like class Article extends Content
20:14 <ryan> that we'll start with
20:14 <yossarian> and then just re-use the Content table
20:14 <ryan> you mean in the code?
20:14 <yossarian> yeah
20:14 <yossarian> are you familiar with single-table inheritance as it relates to object-relational mapping?
20:14 <ryan> yeah hm.
20:14 <ryan> no, i'm not 
20:14 <yossarian> ok
20:14 <ryan> url, or tell me?
20:14 <yossarian> let me do a short explanation 
20:14 <yossarian> basically
20:14 <yossarian> forget about the db for the moment
20:14 <yossarian> any app with a decent sized domain model 
20:14 <yossarian> generally benefits from inheritance in its model classes
20:14 <yossarian> so if you look here: http://dev.bunke.indymedia.org/wiki/DomainModel
20:14 <yossarian> i've put a bunch of classes
20:14 <yossarian> all descended from Content
20:14 <yossarian> so Article and Event for example, share most of their fields
20:14 <yossarian> in such a case, for closely related data classes, in terms of an executable programming language (java, php, ruby, etc) it makes sense to 
                  think of Article and Event as subclasses of content
20:14 <yossarian> the trouble is
20:14 <yossarian> that databases don't know anything aboutt this
20:14 <yossarian> and have flat table structures
20:14 <yossarian> most ORM systems have ways of dealing with this
20:14 <yossarian> one way, used in hibernate and activerecord, is single table inheritance
20:15 <yossarian> so instead of have a table for Article
20:15 <yossarian> a table for Event

20:15 < yossarian> ryan, basically the advantage from an OOP perspective is that we have way less code, and a common interface for all Content objects
20:15 < yossarian> so we put like a hide() method in Content
20:15 < yossarian> and everything gets it
20:19 < startx> i agree about the table layout
20:19 < startx> the data bacomes it context in the logic, not being pre-structered in the db
20:20 < startx> its
20:20 < yossarian> the trouble though is that this isn't built-in to cake so we'd need to override some methods of Cake's activerecord implementation as per 
                   http://www.ifisgeek.com/tutorials/implementing_single_table_inheritance_in_cakephp
20:21 < yossarian> it is what i would do in C#, java, or ruby, but you two are the ones to tell me if this is A Really Bad Idea
20:22 < yossarian> so, in that blog post, dude is overriding findAll somewhat
20:22 < yossarian> i have no idea whether that fucks up anything else
20:23 <@ryan> ok
20:23 <@ryan> so
20:23 < startx> as im not really familiar with cake yet, i wont have to learn a new thing ;)
20:24 <@ryan> ok so i'm still trying to understand parts of this
20:26 <@ryan> i think what would help me understand is to explin the advantage you get here...
20:26 < yossarian> http://www.agiledata.org/essays/mappingObjects.html for a more detailed discussion
20:27 < yossarian> sorry to interrupt, go ahead
20:29 < yossarian> looking at my proposed domain model (which again i don't take as anything other than a conversation-starter), the advantages are: (A) 8 less database 
                   tables, (B) a common interface to all Content objects in the system, giving us an amazing degree of code re-use
20:29 <@ryan> i guess it's just a design methodology, right? combine as many object types you can into one table, extending which objects are eligile by using a types 
              column
20:30 <@ryan> yeah, ok, i like this
20:30 < yossarian> well, it's basically saying "the physical data structure is of much less priority to us than having an OOP model that makes sense"
20:30 < yossarian> so we think primarily in terms of objects
20:31 < yossarian> not in terms of flat rows and columns of data
20:31 <@ryan> i guess its sort of how mysql devlopers deal with the inadequacy felt by not using an object-oriented rdbms
20:31 < yossarian> like, it makes sense to me that Page, Event, and Article are Content and share its methods
20:31 <@ryan> yeah, it does
20:32 < yossarian> it potentially makes sense that Image, Video, Audio, and FileUpload are Content as well (although that's something we would need to discuss more, 
                   probably)
20:32 <@ryan> and you can always override a method if not
20:32 < yossarian> exactly
20:32 <@ryan> one thing to keep in mind on all this
20:33 <@ryan> is that i think the middleware concept i wrote about it the only thing that makes #3 the best
20:33 < yossarian> is #3 us?
20:33 <@ryan> without that i might support plone ;)
20:33 <@ryan> yeah
20:33 < yossarian> ok
20:33 <@ryan> plone is 
20:33 <@ryan> #2
20:34 <@ryan> but that's irrelevant, single table inheritance is workable within that setup
20:34 < yossarian> it doesn't seem to me that STI (single table inheritance rather than sexually transmitted infection) invalidates the middleware idea, yeah
20:34 < yossarian> i had to do some searches on "rails sti" at one point, the result set was really gross
20:34 <@ryan> no, i like STI idea.. its almost like, reminding people of the rules to consider when doing db schemas
20:35 < yossarian> i am very un-data-centric
20:35 <@ryan> because eyeing reuse is something you're always supposed to do
20:35 < yossarian> i usually think in object terms, coming from a c#, actionscript 2, ruby background
20:36 < yossarian> this is really big in the java world
20:36 < yossarian> java devs use something called "hibernate" to do their object-relation mapping stuff
20:36 <@ryan> arghghg fkn luciano!
20:36 < yossarian> hibernate is fucking awesome
20:36 <@ryan> his crappy program probably doesnt use indexes or some shit
20:41 < yossarian> keep in mind that STI unavoidably relaxes database constraints to some extent, because you need a bunch of extra properties in your table and it's not 
                   acceptable to have "not null" in those properties
20:42 < yossarian> because not all subclasses have all properties, but some do
20:42 < yossarian> that is one trade-off when using STI
20:42 < yossarian> also it may interfere with bake
20:42 < yossarian> apparently
20:43 < yossarian> scaffold generation gets interfered with 
20:44 < yossarian> for Article, let's say
20:46 < yossarian> the other way to do things is called Class Table Inheritance (cti)
20:46 < yossarian> with that way of doing things, you have a "content" table, and separate "article", "event", etc tables
20:47 < yossarian> the only thing in "article" and "event" are the extra properties for those classes
20:51 <@ryan> hmmm.
20:51 <@ryan> scaffolding only refers to the auto-generated pages it makes for each table: index, edit, add, etc
20:52 <@ryan> but if it messes with the sql magic of cake, that'd be bad
20:52 < yossarian> in that blog post i sent over, the guy is overriding findAll()
20:52 <@ryan>  hrm
20:52 < yossarian> in order to make the object inheritance work like it does in rails
20:53 < yossarian> it is only overriden in the superclass, once
20:54 < yossarian> like i said earlier, i'd be really surprised if they didn't implement STI in cake in the futre
20:54 < yossarian> future
20:55 <@ryan> ok ell, ill read more about
20:55 <@ryan> and thini about it
20:55 < yossarian> go through the whole blog article in detail
20:55 < yossarian> you and startx will have to make the call
20:43 < yossarian> scaffold generation gets interfered with 
20:44 < yossarian> for Article, let's say
20:46 < yossarian> the other way to do things is called Class Table Inheritance (cti)
20:46 < yossarian> with that way of doing things, you have a "content" table, and separate "article", "event", etc tables
20:47 < yossarian> the only thing in "article" and "event" are the extra properties for those classes
20:51 <@ryan> hmmm.
20:51 <@ryan> scaffolding only refers to the auto-generated pages it makes for each table: index, edit, add, etc
20:52 <@ryan> but if it messes with the sql magic of cake, that'd be bad
20:52 < yossarian> in that blog post i sent over, the guy is overriding findAll()
20:52 <@ryan>  hrm
20:52 < yossarian> in order to make the object inheritance work like it does in rails
20:53 < yossarian> it is only overriden in the superclass, once
20:54 < yossarian> like i said earlier, i'd be really surprised if they didn't implement STI in cake in the futre
20:54 < yossarian> future
20:55 <@ryan> ok ell, ill read more about
20:55 <@ryan> and thini about it
20:55 < yossarian> go through the whole blog article in detail
20:55 < yossarian> you and startx will have to make the call
}}}