Showing messages 1 through 4 of 4.

• "Castor JDO": Simply False Advertising
  2003-05-04 19:59:40  tomdavies [View]
  
  
  You say:"Source and Bytecode enhancements are not ideas that the developer community will like very much". Why would people object to Bytecode enhancements?
  
  If you think that building an ORM yourself is easy, then you probably don't understand all the things which a JDO implementation can do for you:
  
  - transparency, due to persistence by reachability you don't need to explicitly make instances persistent.
  
  - support for inheritence.
  
  - management of relationships between instances, again transparently.
  
  - caching.
  
  I too have written a simple ORM, but I now use JDO extensively, and find that it saves a lot of effort.
  
  Tom
• "Castor JDO": Simply False Advertising
  2004-03-16 17:35:04  tksrajan [View]
  
  
  I am not aganist any frmawork or tool that makes life easier for the developer.
  
  Unfortunately, most of these do the reverse.I have just completed a project that uses OJB for ORM.This was the tool I had recommended from a host of tools evaluated.
  
  Guess what? I found this wanting in many areas, with bugs that the auhors do not think worth fixing
  
  For example if I want to insert records in a batch , ojb.0.9.xx version has no support for it.Likewise if database restarts , I am left with stale connections from the pool.There could be others as well.
  
  This is of course the issue with open source tools.(You can't complain when the stuff is free).My own experience is to use home grown stuff in areas whose execution is critical for the success of the project, or use products that have support from the vendor,else you will end up debugging the vedor's code instead of your own :)
  
  As regards developer comunity not comfortable with bytecode manipulation,this becoes a problem when you have a globally distributed develpoment team that uses the same source from a central repository. versioning binaly files in CVS that are actually source, somehow doesn't make sense
  
  As regards homegrown implemenations, these start at a very simple scale and evelove into full fledged frameworks that support XML mapping, polymorphism, multiple table queries ,complex joins,Object caching and life cycle management.The point is in any well managed project that follows a development methodology( not XP),there is a full set of collateral pertaining to archiecture design and implemenation with profuse documenation will exist. I can vouch for this for all CMM level 3+ or ISO 9001 companies in India.So knowledge transfer is never a problem
  
  Anyway I don't think what Sun dishes out is always holy writ( same about Microsoft as well).So my suggestion about building on our own if time and money permits
  
  Cheers
  
  Sundar

• "Castor JDO": Simply False Advertising
  2002-12-16 11:49:03  robin@ogilviepartners.com [View]
  
  
  Hi Sundar
  
  Firstly, thanks for posting under your own name instead of anonymously. It is easy for readers to dismiss the credibility of anonymous replies.
  
  I had a look at your site but found no "category" for object-relational mapping or relational database access. Are your views on this subject covered under another topic?
  
  SQL allows field-level access to data. As such it is a very efficient API, its only big drawback being the lack of syntax-checking available for SQL at java compile time, which itself is quite understandable.
  
  If you like working with SQL and believe it is no hinderence to your application development efforts you should probably continue to use it.
  
  However, if you feel that:
  1. Your SQL development is time-consuming, or
  2. Your home-grown infrastructure is not sufficiently flexible (e.g. lack of true polymorphism), or
  3. Your applications depend on the presence of a relational database when another paradigm may better suit some deployments (e.g. binary file, ODBMS, etc), or
  4. Your SQL infrastructure is making your domain model inflexible (field names matching column names, and classes not spanning multiple tables, would be prime examples), or
  5. Your SQL infrastructure is "castrating" your object model (value objects with little domain-specific behaviour, but lots of load-save-from-db behaviour), or
  6. Your SQL infrastructure requires developers to have a significant level of skill in (a) SQL and (b) your proprietary infrastructure, or
  7. Your application is based on an infrastructure known in detail by only one or two developers who might (a) leave or (b) make excessive wage demands (I put that one in for fun!)
  
  ...then you should consider JDO.
  
  JDO provides a standard infrastructure that:
  1. Is a standard, and
  2. Is widely implemented by vendors competing on Quality of Service, and
  3. Enables applications to be independent of data store paradigm (relational DB, object DB, etc.), and
  4. Still lets you use SQL if you wish (the Query interface lets you specify a query language other than JDOQL), and
  5. Provides "Transparent Persistence" - for more info read my book "Java Data Objects" in paperback or PDF, or email me, and
  6. Deploys in a client-server, web, or enterprise context, with all the scalability characteristics you'd expect (particularly on the web/enterprise tier), and
  7. Is really cool (I put that one in for fun too!).
  
  No-one said you must use JDO...but I suggest that those who employ JDO wisely will have strategic advantage in software development over competitors who do not, which could be cruicial in the current IT marketplace.
  
  And if you do choose the JDO standard, remember to exclude so-called "Castor JDO" from your evalautions! Ok, I think we've rammed that one home now ;-)
  
  Kind regards, Robin.
  Robin M. Roos
  www.OgilviePartners.com
• "Castor JDO": Simply False Advertising
  2004-03-16 18:04:27  tksrajan [View]
  
  
  Hi,
  
  The problem that I have faced when using third party frameworks (JD, ORM, others) are
  
  1. Bt their very nature, they tend to include code that I might never have any use for, but which can contain bugs. So I have to be often clever enough to bypas the bug(s) , but yet extract the required functionality
  
  2. Very little documentation when they are open source.Whatever documenation there is, normally talks about only what works and very often you would want to know about what does not work.Here is a case in point.
  
  If you hav used JBOSS MQ series(I am refering to the one bundled with JBOSS 3.0.8) , there is a strange problem. A QueueListener that you have registered receives messages whenever some code posts a message to the Queue.This is normal behaviour. However,if JMS server node restarts for whatever reason, the connection factory and connections are stale and so we obtain fresh connection after closing the old listener.We are still able to receive messages on the new connection.
  
  However there is a clock daemon that runs(don't know where, possibly inside the listener?) which checks for the validty of the connection and throws some spyJmsException every one minute with a message that the ping task failed etc.This is fine when JBOSS is down.But this stacktrace is printed even when normalcy is restored.
  
  You might ask, so what is the big deal? It works , does it not? Yes, but if my UAT is dependent on my showing a clean log to the client after a 12 hour load test, I need to hack the log4J file so that the messages emitted by the [Connection Monitor Thread] of JBOSS are not logged at all
  
  Even the $10 documentaion of JBOSS does not contain any reference to this
  
  So I will state my point slightly differently
  
  1. If you have the money, go for an implemenation or framework that you know will be supported or that (even open source) where you have extensive experience
  
  2. If you don't have the money, build one yourself. Simple , initially just concentrating on your immediate needs and slowly developing this to a full fledged framework
  
  Cheers
  
  Sundar