The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 |
From: rob bygrave <rbygr...@yahoo.com>
Date: Sun, 17 May 2009 15:23:59 -0700 (PDT)
Local: Sun, May 17 2009 6:23 pm
Subject: Re: Simplifying Ebean Internals ... by Removing MapBean fuctionality (and DB meta data use)
> 2) Retrieving all meta data at start up seems messy. The meta data is cached (so generally is not retrieved per say). However, it is fair to say that the use of the meta data during initialisation (to find foreign key columns etc) is pretty messy/complex. I was looking at it last night... and compared to just using a naming convention searching the db meta data does look messy/complex to me. > Disagree: 1) Generation (in general) :) No problem. Just to add the reverse engineering (from DB to java) has not had any attention for a long time and needs a re-write/re-visit and look at adding @NotNull and @Length to the generated beans. > So what exactly is lost from the removal of MapBean? I have used MapBeans in that past for utility type programs such as moving/merging data in a table/relational centric way. MapBeans don't require any configuration and are very low tech (which means they are really easy to use). I have not used MapBeans with stored procedures at all. I don't know but suspect hardly anyone (besides myself) is using MapBeans. I hope the users of MapBeans speak up though because removing the DB meta data means the MapBean functionality is going to be hard to keep (and removing the DB meta data looks like it will simplify the internals reasonably significantly). Cheers, Rob. You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||