Re: newbie q #1: CMR across schemas?

I think what I would do here is have one big database project, containing
all the entity beans for the database together with session beans to
access them. I don't think having multiple CMP trying to access the same
table would be a good idea.

Every application would have a separate war file, containing the
interfaces needed to access the common database app.

Anyway this is more of a J2EE architectural design choice than actually
Middlegen related.

.eivind

On Tue, 21 Oct 2003, Michael Harm wrote:

> Hi Eivind.
> 
> Actually, maybe I've made this harder than it is.  I guess I can stick 
> everything into the same schema. But that doesn't by itself solve my 
> problem. Here's concretely what I'd like to do.
> 
> We have a set of tables that implement a medical vocabulary.  Lots of 
> applications use these tables.  One is a clinical data repository.  So 
> it's a nice little project, with ant build script and everything, that 
> one developer is working on.  It gets deployed into jboss as a war and 
> jar. It has tables that have foreign keys into the vocabulary tables.  
> So we can use middlegen to generate an entity bean for, say, 
> VocabularyTerm, Diagnosis, and a bunch of other things, where there's a 
> CMR between Diagnosis.diagnosisCode and VocabularyTerm.termId.  Grand.  
> I could cram everything into the same schema, and explicitly list all 
> my tables that this app uses using the <table> directive and end up 
> with entity beans for VocabularyTerm, Diagnosis, and a couple others.
> 
> Now, someone else is working on an app for a free clinic. They'd like 
> to be able to deploy into jboss, using their own war and jar files, 
> totally independent of the repository project.  Different project, 
> different source tree, different build.xml, everything.  They've got 
> tables of their own, like Patient, that have CMR relations into 
> VocabularyTerm.  Set the middlegen <table> directive to get entity 
> beans for Patient, VocabularyTerm and a couple others.  The 
> VocabularyTerm guy is now common across both applications, and hence 
> both war files.
> 
> If this happens, will jboss freak out that two separate apps (the 
> repository and the free clinic) both have beans for VocabularyTerm?  Or 
> will it figure out that it's the same thing?  Or do I want there to be 
> just *one* VocabularyTerm entity bean in jboss, and reference it from 
> Diagnosis in the repository application, and Patient in the clinic app, 
> maybe using xdoclet tags like @ejb.ejb-external-ref or some such?
> 
> I'd like to avoid having one titanic project with a massive build.xml 
> that deploys every single app we use into a single ear file, with a 
> single massive ejb-jar.xml.  If we have 10 applications deployed to our 
> jboss server, I'd like each to be in its own war file, even if they all 
> reference the (largely stable) VocabularyTerm bean.
> 
> Sorry if I was unclear.  My question isn't really about CMR across 
> schemas I guess, as much as its about sharing Entity beans across apps. 
> Yeah, I know that ejb is supposed to be *all about* sharing primitive 
> things, I just don't know how to do it the *right* way.  All my ejb 
> projects up to now have been entirely self contained.
> 
> I asked the xdoclet crowd about this too, as it may (or may not) be 
> more of an ejbdoclet thing than a middlegen thing.
> 
> Again, sorry for the novice questions.  Any further hand-holding would 
> be greatly appreciated.
> 
> Cheers,
> 
> -mwh
> 
> On Monday, October 20, 2003, at 11:01 PM, Eivind Waaler wrote:
> 
> > Hi, sorry there seems to be no replies to your message.
> >
> > Currently Middlegen does not support more than one schema..
> >
> > Not sure I entirely understand your problem. You want to access the
> > entities from several WAR files? This should be no problem as long as 
> > all
> > WAR files are placed in the same EAR as the ejb-jar file.. If you want 
> > it
> > more split up, you'd have to use some remote session bean facade to 
> > access
> > the entity beans since CMP should use local and not remote
> > interfaces. Using the VALUEOBJECT_REFACTORING_BRANCH from cvs will let 
> > you
> > create such session bean facades..
> >
> > If the problem is having a set of entity beans from different schemas,
> > Middlegen would have to be modified some to support this. I don't even
> > know if this is common practice in J2EE..
> >
> > .eivind
> >
> > On Sat, 18 Oct 2003, Michael Harm wrote:
> >
> >> Hi.
> >>
> >> Sorry if this is a silly one.. I'm new to this.
> >>
> >> We have a set of tables that are sort of a shared resource to be used
> >> across multiple projects.  It's in a schema called "vocabulary" (on
> >> oracle 9i).
> >>
> >> There are other projects that use these tables, with foreign key
> >> relationships into them. Those projects each are in their own schema.
> >>
> >> I'd like to be able to deploy these projects separately into jboss
> >> (3.2.1), each in their own WAR file, but preserving the CMR
> >> relationships to "vocabulary".
> >>
> >> But middlegen operates at the granularity of a single schema, as near
> >> as I can tell.  So the CMR relationships don't happen.  I can run
> >> middlegen twice for a given project, once on, say, "clinical_trials",
> >> and again on "vocabulary", but it doesn't kick out the right cmr 
> >> stuff.
> >>   ejbdoclet lets me add additional entity descriptors to the
> >> ejb-jar.xml, but doesn't seem to have a hook for additional
> >> <ejb-relation> thingies.  And maybe it's a bad idea to have an 
> >> entitity
> >> (say, a bean from the "vocabulary" schema) existing in multiple WAR
> >> files anyway.
> >>
> >> I've tried using oracle's synonyms, creating a synonym of
> >> vocabulary.concept as 'concept' visible in schema 'clinical_trials'
> >> with the fk relationship on that, but middlegen still doesn't see the
> >> 'concept' guy, even if its explicitly named in the <table> directives.
> >> I've also tried leaving off the 'schema' attribute to the middlegen
> >> task and coding the schema prefix in the <table> directives, but it
> >> doesn't see the tables with a schema prefix.
> >>
> >> What's the best practice for having a bean that is used across 
> >> multiple
> >> projects?  Keep everything in the same schema, and each project picks
> >> the stuff it needs using the middlegen <table> directive rather than
> >> scooping in everything?  Is there a danger in having beans referencing
> >> a given table deployed to multiple WAR files?  Or is jboss smart 
> >> enough
> >> to figure this out?
> >>
> >> I'll get more concrete:  in schema vocabulary, there's a table called
> >> CONCEPT with pk concept_id.  In schema clinical_trials there's a table
> >> TRIAL, with a field trial_type_id.  It's got a foreign key 
> >> relationship
> >> to vocabulary.concept(concept_id).  When I do a project relating to
> >> clinical_trials, I'd like to end up with cmr relationships, and be 
> >> able
> >> to get to the concept bean.  And there's another project in schema
> >> clinical_repository that has other tables with fk relationships into
> >> vocabulary.concept(concept_id), and I'd like those to be able to
> >> reference a concept bean as well.
> >>
> >> Any tips on the right way to architect this?
> >>
> >> (in this case, the stuff in the 'vocabulary' schema is all read-only.
> >> That may help with this particular case, and any info that would be
> >> great, but I'd also like to know about the more general case where the
> >> shared schema isn't readonly).
> >>
> >> Thanks!
> >>
> >> Michael Harm
> >> Stanford University School of Medicine
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.net email sponsored by: Enterprise Linux Forum Conference & 
> >> Expo
> >> The Event For Linux Datacenter Solutions & Strategies in The 
> >> Enterprise
> >> Linux in the Boardroom; in the Front Office; & in the Server Room
> >> http://www.enterpriselinuxforum.com
> >> _______________________________________________
> >> middlegen-user mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/middlegen-user
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by OSDN developer relations
> > Here's your chance to show off your extensive product knowledge
> > We want to know what you know. Tell us and you have a chance to win 
> > $100
> > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > _______________________________________________
> > middlegen-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/middlegen-user
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> middlegen-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/middlegen-user
> 



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54