[Ogden] ogcomment issue
Trans
the debug output:
DEBUG: CREATE TABLE ogcomment (body text, oid integer PRIMARY KEY)
INFO: Created table ogcomment.
DEBUG: SELECT * FROM ogcomment LIMIT 1
DEBUG: CREATE TABLE ogcomment (oid integer PRIMARY KEY, author_oid
integer, body text)
DEBUG: SELECT * FROM ogcomment LIMIT 1
DEBUG: CREATE TABLE ogcomment (oid integer PRIMARY KEY, article_oid
integer, body text)
DEBUG: SELECT * FROM ogcomment LIMIT 1
As you can see, it tries to create the same table three times. I
suspect what it happening is the first time works as indicated by the
INFO, and the others silently fail. In the code, the issue appears a
little more complicated. We have:
class Comment
attr_accessor :body, String
class ArticleComment < Comment
belongs_to Article
class UserComment < Comment
belongs_to :author, User
class Article
has_many :comments, ArticleComment
class User
has_many :comments, UserComment
So I think that the three comment tables are being created by Comment,
ArticleComment and UserComment, but they are clearly not getting the
right table names. So that's the major clue. We just need to find
where the table names are being generated and fix.
Also, technically Comment need not have a table at all since it is
just being used as a base class. I'm not sure how easy that will be to
fix though.
T.
_______________________________________________
Ogden-developers mailing list
Ogden-de...@rubyforge.org
http://rubyforge.org/mailman/listinfo/ogden-developers
* William
right table names. So that's the major clue. We just need to find
where the table names are being generated and fix.
Also, technically Comment need not have a table at all since it is
just being used as a base class. I'm not sure how easy that will be to
fix though.
I am not definite if a tool like og knows that (or can know it??) It would be cool if it can work that out.
At the same time, we might use the OO language to label base classes like that as 'Abstract' anyway as an optional attribute.
I took another look at the demo ... My understanding here is that the Comment class is the table implementation of all comments and it is NOT a an abstract class, it is what I might call an "Implementation Vehicle" class
Both are only use to establish the 'Belongs to' relationships.
In light of that interpretation, we could think of ArticleComment and UserComment as "linkage only".
I would say for now, we leave the conceptual areas "as is" until the code is working in a functional way.
:-)
aloha,
\_w_/
________________________________
º http://mbimarketing.wordpress.com
º http://adroit-process.blogspot.com
Lars Olsson
Well, before we can start to investigate what tables need to be created, wouldn't it be nice to have a definition of what each "relating" method is supposed to do? My relational db modeling skills isn't to good, but I believe it works kind of like below:
Assuming that A is the current table, B is a related table and C is a join table needed by a relation between A and B
A.property creates a field in A
A.has_one creates a field in A. The field is pointing to a unique key (row) in B
A.has_many creates a field in B. The field is pointing to a unique key (row) in A
A.many_to_many creates two fields in C, each pointing to a unique key (row) in A and B
A.belongs_to creates a field in A. The field is pointing to a unique key (row) in B
Please feel free to correct me/nake clarifications!
/lasso
________________________________________
Lars Olsson
lasso3000(at)yahoo.se
--- Den lör 2009-02-14 skrev Trans <tran...@gmail.com>:
___________________________________________________
Sök efter kärleken!
Hitta din tvillingsjäl på Yahoo! Dejting: http://ad.doubleclick.net/clk;185753627;24584539;x?http://se.meetic.yahoo.net/index.php?mtcmk=148783
* William
Hope your well ... I'll repeat for reinforcement, that I'd like to see the code base stable and working "as intended" :-) The implications for property and fields, are specifics to the og ruby library -- In their implemetation of the Object graph model (see link below) over an under-lying relational (or other ) implementation.
As to the the entity relationship modelling, we should start with the relational algebras from ::
- Entity relationship model .... http://en.wikipedia.org/wiki/Entity_relationship
- Data modelling ... http://en.wikipedia.org/wiki/Data_modeling
In the 'old days' the best data base performance was from 'clean' Networked Databases. All messy databases of all architectures created problems. The OG method creates a newtorked
- Object Graph ..................... http://en.wikipedia.org/wiki/Object_graph
- Network Database model .... http://en.wikipedia.org/wiki/Network_database
The specific case of the Comments table; my interpretation of the observed behaviour is that I like the implication. That ... seems to show that Relationship-only subclasses of Comments are able to be housed in the OG_Comments table. (That's just my reading of the information/guess).
Mind you ... I admit that it's a pretty sweet idea, but I think there's a flaw. You also need a column to indicate the Actual Class any particular Row represents in the table. (I worked for 9 years on a product that used to do just that).
I reckon stable code that does the Expected is a better step forward. What I mean here by expected is ...
||
|| class ArticleComment < Comment
|| belongs_to Article
||
|| class UserComment < Comment
|| belongs_to :author, User
||
* OG_USERCOMMENT
* OG_ARTICLECOMMENT
Not one, an OG_COMMENT. Following my conversation so far, I'd see a shared OG_COMMENT table as an optimisation, not necessarily a default behaviour. That is a late discussion, imho.
Regards,
Will
P.S.
If you refer to C.J.Date's book, "What, not How?!" he points out that relational algebra was the key factor in the resilience of relational database model implementations. Efficeient models would use the best solution under-the-hood to implement a BUSINESS MODEL :-)
Which sometimes I consider it is worth reminding people the reason to do this stuff is to build efficient operational models for a use case, enterprice, game, etc. That's why I like OG, it goes a long way to dealing with the appropriate end-user-case. :-)
Well, before we can start to investigate what tables need to be created, wouldn't it be nice to have a definition of what each "relating" method is supposed to do? My relational db modeling skills isn't to good, but I believe it works kind of like below:
Assuming that A is the current table, B is a related table and C is a join table needed by a relation between A and B
A.property creates a field in A
A.has_one creates a field in A. The field is pointing to a unique key (row) in B
A.has_many creates a field in B. The field is pointing to a unique key (row) in A
A.many_to_many creates two fields in C, each pointing to a unique key (row) in A and B
A.belongs_to creates a field in A. The field is pointing to a unique key (row) in B
Please feel free to correct me/nake clarifications!
Trans
On Feb 16, 9:11 am, "* William" <william.full.m...@gmail.com> wrote:
> Hi all :-)
>
> Hope your well ... I'll repeat for reinforcement, that I'd like to see the
> code base stable and working "as intended" :-) The implications for
> property and fields, are specifics to the og ruby library -- In their
> implemetation of the Object graph model (see link below) over an under-lying
> relational (or other ) implementation.
>
> As to the the entity relationship modelling, we should start with the
> relational algebras from ::
>
> - Entity relationship model ....
> http://en.wikipedia.org/wiki/Entity_relationship
> - Data modelling ...http://en.wikipedia.org/wiki/Data_modeling
>
> However, I need to stress that object graphs don't do "relational algebra"
> they may _map_ on object onto a relational algebra model like a Relational
> Database. A little history is in order now.
>
> In the 'old days' the best data base performance was from 'clean' Networked
> Databases. All messy databases of all architectures created problems. The
> OG method creates a newtorked
>
> - Object Graph .....................
> http://en.wikipedia.org/wiki/Object_graph
> - Network Database model ....
> http://en.wikipedia.org/wiki/Network_database
>
> Network models are pretty cool, as long as you CAN take care of the
> 'relational rules' and implications.
>
> The specific case of the Comments table; my interpretation of the observed
> behaviour is that I like the implication. That ... seems to show that
> Relationship-only subclasses of Comments are able to be housed in the
> OG_Comments table. (That's just my reading of the information/guess).
>
> Mind you ... I admit that it's a pretty sweet idea, but I think there's a
> flaw. You also need a column to indicate the Actual Class any particular
> Row represents in the table. (I worked for 9 years on a product that used
> to do just that).
>
> I reckon stable code that does the Expected is a better step forward. What
> I mean here by expected is ...
>
> ||
> || class ArticleComment < Comment
> || belongs_to Article
> ||
> || class UserComment < Comment
> || belongs_to :author, User
> ||
>
> Two tables (not one)
>
> * OG_USERCOMMENT
> * OG_ARTICLECOMMENT
>
> Not one, an OG_COMMENT. Following my conversation so far, I'd see a shared
> OG_COMMENT table as an optimisation, not necessarily a default behaviour.
> That is a late discussion, imho.
Very good point. And I think something to consider for the future,
once what we have is working satisfactorily.