This is recent exchange which might answer some
questions on the advantages of using an OR mapper.
george stewart wrote:
> > Is there any action which causes osage to generate
> > query with a join?
> > I would assume that when there is a many to one
> > relationship that you
> > use an inner join, like If an emp is in only one
> > dept, when someone
> > requests emp objects, you'll join emp table and
> > table, and generate
> > Emp objects which hold Dept Objects. Is that
> No, it still generates separate query to get the
> department. Doesn't this give more general design?
> > Question two: the cache stores the array of
> > using what as the
> > key? The SQL string? The criteria object?
> The criteria object. This is much more efficient
> because it's expensive to generate the string.
> Secondly, it is not possible to use string because
> system is designed for prepared statements.
> > 3: How do you keep the cache up to date? Do you
> > re-execute the query
> > every so often?
> That's the approach of poolman, and I could do this
> but seems like waste of resources. Poolman's
> could only work on small systems.
> Instead, when request comes to cache, cache checks
> next cycle for removing items. If its time for
> flushing, it runs thru list removing stale queries.
> So refresh is only on demand.
> > 4: When are result sets removed from the cache?
> > it based on last
> > access time?
> I partly answered that one above. When items are
> stored, the item is stamped with currentMillis +
> expireSeconds. This provides aging. If no
> expireSeconds is specified for class, query remains.
> > 5: If data is written to the DB does that cause
> > cache to be
> > modified?
> That would be nice enhancement. I think this might
> require 2-level cache. 1st level holds (criteria,
> list of identities) and 2nd holds (identity, objects
> ) for an object.
> I don't know if it's worth it.
> > If osage could write all changes through the cache
> > (meaning that the
> > cache is updated, and the db is updated), then if
> > had one box running
> > an osage app, and nothing modifying the db except
> > that app, I would
> > always have an up to date cache.
> > If I then distributed that app on multiple boxes,
> > would need a
> > distributed write through cache, and then I could
> > have multiple boxes
> > with up to date cache, but still any updates made
> > the DB not through
> > osage would screw up my cache.
> > I still think that a distributed cache would be
> > much worthwhile,
> > although difficult to develop.
> Is it worthwhile? If you use session beans
> (application server), you can transfer the
> retrieval/save work to the server.
> > The rules imposed on me by the structure of these
> > systems causes too
> > much additional code to run, and I have to write
> > code I have anyway
> > to get the same features, so I get nothing for it.
> I don't believe that you have to write additional
> for the OR mapper. And it doesn't have to run
> additional code.
> One advantage of osage over low-level system is
> you have to use boolean. How do you handle this?
> There's two issues. Retrieving data, and
> the schema. osage supports this with
> mapping and data conversions. So attribute type can
> be boolean, and column is a char. If the database
> supports something more efficient you can use it by
> changing mapping instead of code. No recompling.
> It generates code correctly, and gen's schema too.
> I need to add data conversion for bind params to
> complete this.
> Another not insignificant advantage is support for
> user-defined types. With osage, you could support a
> currency type, and conversion is handled
> "lazy" loading and query cache are very nice to
> Another small, useful feature in osage is specifying
> case-insensitive searches in mapping. Just specify
> ignorecase="true" in column mapping and all queries
> this attribute are case insensitive with no code
> > Also, do you support many <--> many relationships,
> > and multi field
> > primary keys?
> For many-many, you have to use join object. Multi
> are there.
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.