tag:blogger.com,1999:blog-7318041760132105098.post1931821760936272318..comments2017-09-19T18:51:58.865-07:00Comments on Igor Polevoy Blog: ActiveJDBC Features - Birds ViewIgor Polevoyhttp://www.blogger.com/profile/03725729050038133735noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-7318041760132105098.post-61131243957448909862010-04-23T14:46:52.246-07:002010-04-23T14:46:52.246-07:00Blacktiger, you wrote:
"Table was just a name...Blacktiger, you wrote:<br />"Table was just a name I came up with on the fly.."<br /><br />I thought I answered this in a previous comment. Base class could be used to do ad hoc SQL, while the Model class is for ORM.<br /><br />thanks,<br />igorIgor Polevoyhttps://www.blogger.com/profile/03725729050038133735noreply@blogger.comtag:blogger.com,1999:blog-7318041760132105098.post-53481287119593292102010-04-23T09:28:09.637-07:002010-04-23T09:28:09.637-07:00Blacktiger, you wrote:
"A couple more thought...Blacktiger, you wrote:<br />"A couple more thoughts..."<br /><br />Well, correct. The Person class is a client class, and a developer can write a constructor that takes in a map and calls fromMap() there.<br /><br />To answer your second question, the list that is returned from all the finder methods is actually a LazyList. This class only queries the DB when you start iterating through it.<br /><br />thanks,<br />igorIgor Polevoyhttps://www.blogger.com/profile/03725729050038133735noreply@blogger.comtag:blogger.com,1999:blog-7318041760132105098.post-44767529476902554992010-04-23T08:58:59.621-07:002010-04-23T08:58:59.621-07:00Table was just a name I came up with on the fly. P...Table was just a name I came up with on the fly. Perhaps you could simple create an instance of model directly, or use your Base object.<br /><br />Most of the tables would have business logic, but I find that occasionally you just need to store and retrieve data directly from the database without the need to do anything particularly special with the object itself. Why force yourself to write extra code (even though it isn't much)? I could also see a situation in which you need to add a table to a running app but don't want to do a full build. You could drop a jsp in to do what you need to with the data until the next build when you replace it with a real object.Blacktigerhttps://www.blogger.com/profile/02629290772651452425noreply@blogger.comtag:blogger.com,1999:blog-7318041760132105098.post-50272624763607244012010-04-22T23:14:59.351-07:002010-04-22T23:14:59.351-07:00blacktiger, thanks for suggestion. You write: &quo...blacktiger, thanks for suggestion. You write: "...without even an empty object.." and then you proceed to create an empty object type Table. <br /><br />Nevertheless, your approach is interesting. However, the ActiveJDBC is a true ORM and it is expected that you have logic (at least some basic validations) in your model. In other words, ActiveJDBC philosophy is against a way of coding called "Anemic Model" and for creation of meaningful models. <br /><br />However, ActiveJDBC also provides a class called Base. This class encapsulates functionality similar to what you are proposing, but uses standard Java classes: Map, List, etc.<br /><br />I will write a blog entry with examples on Base.<br /><br />In any case, thanks for your input.Igor Polevoyhttps://www.blogger.com/profile/03725729050038133735noreply@blogger.comtag:blogger.com,1999:blog-7318041760132105098.post-19031889101178534192010-04-22T22:50:44.044-07:002010-04-22T22:50:44.044-07:00A couple more thoughts...
1) Why not have a const...A couple more thoughts...<br /><br />1) Why not have a constructor for the Person class that takes a map directly instead of a fromMap method?<br /><br />2) I don't know if you already considered this, but what about returning a list of records that doesn't actually query the database until you request some values?Blacktigerhttps://www.blogger.com/profile/02629290772651452425noreply@blogger.comtag:blogger.com,1999:blog-7318041760132105098.post-69162451647975542222010-04-22T22:46:38.351-07:002010-04-22T22:46:38.351-07:00That looks great. What about a feature to let you ...That looks great. What about a feature to let you access a table without even an empty object? Something like:<br /><br />Table person = new Table("person");<br />//find by id:<br />Row p = person.findById(0);<br /><br />//find first:<br />Row p = person.first("name = ?", "John");<br /><br />That way you don't have to go creating objects unless you actually have business logic for them. If you have tables where all you do is load and store data in them you don't have to clutter up your project with extra files.Blacktigerhttps://www.blogger.com/profile/02629290772651452425noreply@blogger.comtag:blogger.com,1999:blog-7318041760132105098.post-28594162564656136492010-04-20T20:38:18.116-07:002010-04-20T20:38:18.116-07:00Thank you, Ron!
Well, the reverse generation of t...Thank you, Ron!<br /><br />Well, the reverse generation of the entities from tables makes sense in cases you have code in those entities (read Hibernate with all the XML and getters and setters). For ActiveJDBC, for instance for a table People, an entity will look like this:<br /><br /><br />public class Person extends Model{}<br /><br /><br />Really nothing to generate, while it comes complete with the power of the framework. <br />That was one reason not to generate entities, while there is another: <br />I just do not believe that a developer writing DB code should be far removed from it. Therefore, I think that ActiveRecord (IMHO) is a model here with it's migrations capability (although not too happy about it's syntax). Basically, you generate your DDL, then write a model/entity class to support it. <br /><br />I hope this clears it (my view :))<br /><br />cheers,<br />igorIgor Polevoyhttps://www.blogger.com/profile/03725729050038133735noreply@blogger.comtag:blogger.com,1999:blog-7318041760132105098.post-80749564315585037492010-04-20T20:14:49.252-07:002010-04-20T20:14:49.252-07:00Hi Igor,
I really like the amount of functionalit...Hi Igor,<br /><br />I really like the amount of functionality this approach provides, while not bringing in all the baggage of a Hibernate, JPA, etc. It feels like something that hits the sweet spot where it works well for 90%+ of the scenarios where you need to access a RDBMS, with the minimal amount of baggage. Don't get me wrong, I'm glad to keep Hibernate in my tool belt, but there is definitely baggage that goes along with it; whether it's conceptual (e.g. sessions, caching, mappings, criteria queries), or the other libraries you have to drag in with it. I guess that's the price of doing so much in one framework.<br /><br />What about a feature to reverse generate your POJOs from existing tables?Anonymousnoreply@blogger.com