[Nitro] help with og!
transfire at gmail.com
Sun Dec 11 19:12:15 EST 2005
On 12/5/05, zimba-tm <zimba.tm at gmail.com> wrote:
> On 05/12/05, TRANS <transfire at gmail.com> wrote:
> > > So Og can create an empty object, and detect the attribute's types.
> > > What do you think of that idea ?
> > If I understand what you're proposing...
> > It's tricky. You still need a way to exclude/include attributes and if
> > you depend soley on the type of the attribute itself what happens if
> > its not the same type as the field in the DB? --which can happen if
> > another object of same class had a different type of value for an
> > attribute previously.
> Ok, you understood what I meant. I'm not sure it's an ideal solution,
> but I'm here to talk about it.
> Basically, here is how my idea would look like :
> class Item
> def initialize(*args) # or ( name='', price = 0.00, once = Type::Ignore )
> @name = '' # or Type::String
> @price = 0.00 # or Type::Float
> @once = Type::Ignore
Well, the Type::Ignore won't do. But you could still use an annotation.
ann "@once", :og_ignore => true
The annotations systems used by Og is completely free form, so
attributes can be annotated just as easily as methods. And recall
there's other info related to SQL that has to be given at times too,
like default values, or if a field is indexed, etc.
> Finally, what happens in the actual Og implementation when a data type
> given is not compatible with the database field format ? I see three
> possibilities :
> 1) Define transformations to the desired storage format
That's reasonable, but can't count for every possibility.
> 2) Dump the invalid data
> 3) Add a dump field to put the invalid data inside
These is too relaxed. I think if #1 fails it should rollback and raise an error.
It's an interesting approach and yes, I think it could work. But
details would have to be worked out. Yet it's quite different from how
Og works now. So the other question to ask, is such a change
More information about the Nitro-general