Oliver, Thanks. This proposal has been put forward before.
- The code is generated. If the top class is annotated @MappedSuperclass, why not label every abstract class that is top of its hierarchy @MappedSuperclass. That's the simplest change to the compilation strategy that generates this code. - This fails for the contained element. Specifically, if you also label the top of the contained element hierarchy @MappedSuperclass, then hibernate fails to be able to find the Id of the subclasses. - Futher, how does the compilation scheme know which top class is contained. That's not possible because someone could always come along and add another class that was a container. So, this fails to be compositional, in the extreme. Best wishes, --greg On Tue, Jun 23, 2009 at 4:55 PM, Oliver Lambert <olambo...@gmail.com> wrote: > I don't understand from the code sample why AbstractContainer has to be an > entity or > have a table or id annotation. I'd be looking at just using the > @MappedSuperclass annotation. > > > On Wed, Jun 24, 2009 at 9:27 AM, Meredith Gregory < > lgreg.mered...@gmail.com> wrote: > >> Kris, >> >> Thanks for this code sample. i will study and see if it offers a way >> around the conundrum. In the meantime, here's a code >> sample<http://svn.biosimilarity.com/src/open/codesamples/trunk/hibernate/hbex/>illustrating >> exactly what i'm talking about. >> >> Best wishes, >> >> --greg >> >> >> On Tue, Jun 23, 2009 at 2:21 PM, Kris Nuttycombe < >> kris.nuttyco...@gmail.com> wrote: >> >>> >>> Oops, forgot a member of the hierarchy, inline below: >>> >>> On Tue, Jun 23, 2009 at 3:19 PM, Kris >>> Nuttycombe<kris.nuttyco...@gmail.com> wrote: >>> > I'm just so puzzled by this thread because I have the following entity >>> > hierarchy in my app: >>> > >>> > @Entity >>> > @Inheritance(strategy = InheritanceType.JOINED) >>> > @Table(name = "payment_source_transaction") >>> > public abstract class PaymentSourceTransaction<T extends >>> PaymentSource<T>> >>> > extends SubscriptionTransaction implements >>> > MonetaryTransaction<T>, Serializable { >>> > >>> > @ManyToOne(cascade = {CascadeType.MERGE, CascadeType.PERSIST}, >>> > optional = false, targetEntity = PaymentSource.class) >>> > private T paymentSource; >>> > >>> > ... >>> > } >>> > >>> > @Entity >>> > public abstract class CreditCardTransaction extends >>> > PaymentSourceTransaction<CreditCard> { ... } >>> > >>> >>> @MappedSuperclass >>> public abstract class VoidableCCTransaction extends >>> CreditCardTransaction implements Serializable { ... } >>> >>> @OneToOne(cascade = {CascadeType.MERGE, CascadeType.PERSIST}, >>> mappedBy="voidedTransaction") >>> private CCVoidTransaction voidTransaction; >>> >>> > @Entity >>> > public class CCAuthTransaction extends VoidableCCTransaction >>> > implements AuthTransaction<CreditCard>, Divisional, Serializable { .. >>> > } >>> > >>> > @Entity >>> > @Inheritance(strategy = InheritanceType.SINGLE_TABLE) >>> > public abstract class CCCaptureTransaction extends >>> > VoidableCCTransaction implements Serializable, >>> > CaptureTransaction<CreditCard> { >>> > private static final long serialVersionUID = 1L; >>> > >>> > @OneToOne(cascade = {CascadeType.PERSIST, CascadeType.MERGE}) >>> > private CCAuthTransaction authTransaction; >>> > >>> > ... >>> > } >>> > >>> > @Entity >>> > public class EcometryCaptureTransaction extends CCCaptureTransaction >>> > implements EcometryOrder, Serializable { ... } >>> > >>> > @Entity >>> > @Inheritance(strategy = InheritanceType.JOINED) >>> > public abstract class PaymentSource<T extends PaymentSource<T>> >>> > extends UUEntity implements MutationControlled<T>, Serializable { ... >>> > } >>> > >>> > @Entity >>> > public class CreditCard extends PaymentSource<CreditCard> implements >>> > Addressable, Serializable { ... } >>> > >>> > @Entity >>> > public class CheckingAccount extends PaymentSource<CheckingAccount> >>> > implements Serializable { ... } >>> > >>> > This works for me without difficulty. What am I missing that is >>> > different about this scheme than the one that you describe? >>> > >>> > Kris >>> > >>> > >>> > >>> > On Tue, Jun 23, 2009 at 11:29 AM, Meredith >>> > Gregory<lgreg.mered...@gmail.com> wrote: >>> >> Derek, >>> >> >>> >> i completely concur. i wanted to give it a serious go, however, before >>> i >>> >> abandoned it. The issue is that so much of the incumbent technology >>> goes >>> >> across this object-relational boundary, i needed a simple case to >>> justify >>> >> walking away from this technology. This example provides it. To see >>> just how >>> >> non-complex it is, let me state it in common sense terms. >>> >> >>> >> Suppose we are building an app for a manufacturing firm, and the firm >>> ships >>> >> out its goods in different kinds of containers: plastic-coated >>> cardboard >>> >> boxes, metal boxes, etc. >>> >> Suppose that different kinds of materials go into different kinds of >>> boxes, >>> >> and sometimes medicinal or toxic substances go into these containers; >>> but, >>> >> every container gets a manifest. When the container contains these >>> materials >>> >> that need to be handled with care or attention, the manifest is a >>> special >>> >> kind of certified manifest. >>> >> >>> >> We might imagine that this firm has already constructed an object >>> model that >>> >> looks like >>> >> >>> >> abstract class Container { ...; Manifest getManifest(); void >>> setManifest( >>> >> Manifest manifest ); ... } >>> >> class CardboardContainer extends Container { ... } >>> >> class MetalContainer extends Container { ... } >>> >> abstract class Manifest { ... } >>> >> class StdManifest extends Manifest { ... } >>> >> class CertifiedManifest extends Manifest { ... } >>> >> >>> >> We need to work with their existing infrastructure. However, this >>> >> situation/model breaks Hibernate's implementation of JPA. That such a >>> simple >>> >> situation would cause problems indicates to me that these technologies >>> have >>> >> never been used in any significant way in production -- otherwise they >>> would >>> >> have bumped into such a common case. If i'm wrong about something, >>> here, i'd >>> >> love to be disabused of my misunderstanding(s). Currently, i feel i >>> have >>> >> enough justification to go to a different kind of solution, such as a >>> >> LINQ-based solution. >>> >> >>> >> Best wishes, >>> >> >>> >> --greg >>> >> >>> >> On Mon, Jun 22, 2009 at 5:46 PM, Derek Chen-Becker < >>> dchenbec...@gmail.com> >>> >> wrote: >>> >>> >>> >>> For sufficiently complex relationships, JPA is not a good fit. Beyond >>> a >>> >>> certain point it's usually simpler to roll your own. I think that >>> this is >>> >>> somewhat of a failing of the model, but it's not a simple problem to >>> solve >>> >>> in the generic case. >>> >>> >>> >>> Derek >>> >>> >>> >>> On Mon, Jun 22, 2009 at 6:45 PM, Derek Chen-Becker < >>> dchenbec...@gmail.com> >>> >>> wrote: >>> >>>> >>> >>>> Ah, sorry, I lost track of the thread. >>> >>>> >>> >>>> On Mon, Jun 22, 2009 at 4:55 PM, Meredith Gregory >>> >>>> <lgreg.mered...@gmail.com> wrote: >>> >>>>> >>> >>>>> Derek, >>> >>>>> >>> >>>>> You are correct and i noted and reported this on Scala on Friday. >>> >>>>> However, if you have a chain of the form >>> >>>>> >>> >>>>> AbstractClass <- Class <-contains- AbstractClass <-Class >>> <-contains- ... >>> >>>>> >>> >>>>> The @MappedSuperclass solution fails at level 2. >>> >>>>> >>> >>>>> Best wishes, >>> >>>>> >>> >>>>> --greg >>> >>>>> >>> >>>>> On Mon, Jun 22, 2009 at 3:52 PM, Derek Chen-Becker >>> >>>>> <dchenbec...@gmail.com> wrote: >>> >>>>>> >>> >>>>>> Something I just want to throw out into the discussion: Since >>> you're >>> >>>>>> using table-per-class, having a @Table annotation on >>> AbstractContainer >>> >>>>>> doesn't do anything since abstract classes can't have instances. >>> Tables are >>> >>>>>> only generated for abstract classes if you're using a JOINED >>> inheritance >>> >>>>>> strategy. You might want to look at using the MappedSuperclass >>> annotation >>> >>>>>> for the abstract base class instead. If I change the >>> AbstractContainer def >>> >>>>>> to: >>> >>>>>> >>> >>>>>> @MappedSuperclass >>> >>>>>> public abstract class AbstractContainer implements >>> java.io.Serializable >>> >>>>>> { >>> >>>>>> >>> >>>>>> and then modify MySampleFuContainer to: >>> >>>>>> >>> >>>>>> public class MySampleFuContainer extends AbstractContainer { >>> >>>>>> >>> >>>>>> then I seem to get the proper schema: >>> >>>>>> >>> >>>>>> create table lingo_production.MySampleFuContainer_table ( >>> >>>>>> id varchar(255) not null, >>> >>>>>> uuid varchar(255), >>> >>>>>> mysamplingmumble__idSuper varchar(255), >>> >>>>>> primary key (id), >>> >>>>>> unique (uuid) >>> >>>>>> ); >>> >>>>>> >>> >>>>>> >>> >>>>>> Having said that, I think that the behavior you're currently >>> seeing >>> >>>>>> appears to be a bug. >>> >>>>>> >>> >>>>>> Derek >>> >>>>>> >>> >>>>>> On Mon, Jun 22, 2009 at 3:43 PM, Meredith Gregory >>> >>>>>> <lgreg.mered...@gmail.com> wrote: >>> >>>>>>> >>> >>>>>>> Kris, >>> >>>>>>> >>> >>>>>>> Here is a link to the self-contained example that now uses just >>> Java. >>> >>>>>>> i included the target dir in the repo to speed up investigation, >>> but you can >>> >>>>>>> just blow that away and build from scratch. The example is >>> currently written >>> >>>>>>> to Java1.6, but also exhibits the same behavior under Java1.5. To >>> run the >>> >>>>>>> example >>> >>>>>>> >>> >>>>>>> > svn co >>> >>>>>>> > >>> http://svn.biosimilarity.com/src/open/codesamples/trunk/hibernate >>> >>>>>>> ... >>> >>>>>>> > env PATH=<path-to-java1.6>:$PATH JAVA_HOME=<path-to-java1.6> >>> mvn >>> >>>>>>> > clean compile process-classes >>> >>>>>>> >>> >>>>>>> If you switch comment and decl at line 22 in >>> >>>>>>> src/main/java/maxb/hbex2/MySampleFuContainer.java then you see >>> the error. >>> >>>>>>> The schema goes from >>> >>>>>>> >>> >>>>>>> create table lingo_production.MySampleFuContainer_table ( >>> >>>>>>> id_AbstractContainer varchar(255) not null, >>> >>>>>>> varchar(255) not null, >>> >>>>>>> uuid varchar(255), >>> >>>>>>> mysamplingmumble__idSuper varchar(255), >>> >>>>>>> primary key (id), >>> >>>>>>> unique (uuid) >>> >>>>>>> ); >>> >>>>>>> >>> >>>>>>> to >>> >>>>>>> >>> >>>>>>> create table lingo_production.MySampleFuContainer_table ( >>> >>>>>>> id_AbstractContainer varchar(255) not null, >>> >>>>>>> id varchar(255), >>> >>>>>>> mysamplingmumble_ tinyblob, >>> >>>>>>> uuid varchar(255), >>> >>>>>>> primary key (id_AbstractContainer), >>> >>>>>>> unique (id_AbstractContainer) >>> >>>>>>> ); >>> >>>>>>> >>> >>>>>>> Best wishes, >>> >>>>>>> >>> >>>>>>> --greg >>> >>>>>>> >>> >>>>>>> On Mon, Jun 22, 2009 at 1:38 PM, Meredith Gregory >>> >>>>>>> <lgreg.mered...@gmail.com> wrote: >>> >>>>>>>> >>> >>>>>>>> Kris, >>> >>>>>>>> >>> >>>>>>>> Thanks for the suggestion. i've now got a tiny little example >>> that >>> >>>>>>>> compiles on its own that illustrates the problem. Changing the >>> inheritance >>> >>>>>>>> strategy to JOINED makes no difference. Hibernate still does the >>> wrong >>> >>>>>>>> thing. >>> >>>>>>>> >>> >>>>>>>> Best wishes, >>> >>>>>>>> >>> >>>>>>>> --greg >>> >>>>>>>> >>> >>>>>>>> On Mon, Jun 22, 2009 at 8:55 AM, Kris Nuttycombe >>> >>>>>>>> <kris.nuttyco...@gmail.com> wrote: >>> >>>>>>>>> >>> >>>>>>>>> This may be off the mark, but I'm wondering if the reason that >>> >>>>>>>>> you're >>> >>>>>>>>> having difficulty with the parallel inheritance hierarchy >>> problem is >>> >>>>>>>>> not your use of TABLE_PER_CLASS inheritance. In my application, >>> I >>> >>>>>>>>> have >>> >>>>>>>>> a similar construct, but I am using JOINED_TABLE inheritance. >>> This >>> >>>>>>>>> allows for a normal foreign key relationship to be created in >>> the >>> >>>>>>>>> database between C2_table and the base table for CThing, with >>> the >>> >>>>>>>>> result that Hibernate will generate the query for CThing member >>> as a >>> >>>>>>>>> union. Using table per class inheritance, I would expect >>> Hibernate >>> >>>>>>>>> to >>> >>>>>>>>> need to synthesize an additional dtype field in C2_table along >>> with >>> >>>>>>>>> the key column in order to enforce the uniqueness of the keys >>> to the >>> >>>>>>>>> joined entities, and I don't believe that it does this. >>> >>>>>>>>> >>> >>>>>>>>> I'm not sure how the fact that the code is generated is >>> particularly >>> >>>>>>>>> relevant; surely if it's possible to hand-write a successful >>> >>>>>>>>> solution, >>> >>>>>>>>> then your code generator could be made aware of how to >>> construct a >>> >>>>>>>>> viable solution? >>> >>>>>>>>> >>> >>>>>>>>> Kris >>> >>>>>>>>> >>> >>>>>>>>> On Fri, Jun 19, 2009 at 8:47 PM, Meredith >>> >>>>>>>>> Gregory<lgreg.mered...@gmail.com> wrote: >>> >>>>>>>>> > All, >>> >>>>>>>>> > >>> >>>>>>>>> > i had a similar problem and found the source of the issues. >>> Spse >>> >>>>>>>>> > you have a >>> >>>>>>>>> > container hierarchy (CTop <- C2) side-by-side with a >>> contained >>> >>>>>>>>> > hierarchy >>> >>>>>>>>> > (CThing <- CThing1). The inheritance at the top of the >>> container >>> >>>>>>>>> > hierarchy, >>> >>>>>>>>> > CTop, causes hibernate to bail on tracking the relations and >>> punt >>> >>>>>>>>> > to >>> >>>>>>>>> > embedded values instead. Rewriting the top to be a >>> >>>>>>>>> > @MappedSuperClass fixes >>> >>>>>>>>> > the problem in this specific case. However, if your hierarchy >>> is >>> >>>>>>>>> > deep, >>> >>>>>>>>> > you're screwed. >>> >>>>>>>>> > >>> >>>>>>>>> > If anybody has a suggestion for a workaround, i'm all ears. >>> The >>> >>>>>>>>> > problem is >>> >>>>>>>>> > that it would appear that both Mr Crowley and i are >>> generating >>> >>>>>>>>> > Java + JPA >>> >>>>>>>>> > code. So, the solution needs to be algorithmic and not 1-off. >>> >>>>>>>>> > >>> >>>>>>>>> > Perhaps the best solution is to find an alternative to >>> hibernate >>> >>>>>>>>> > as this is >>> >>>>>>>>> > a particularly irritating bug. >>> >>>>>>>>> > >>> >>>>>>>>> > Best wishes, >>> >>>>>>>>> > >>> >>>>>>>>> > --greg >>> >>>>>>>>> > >>> >>>>>>>>> > @Entity >>> >>>>>>>>> > @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) >>> >>>>>>>>> > abstract class CTop { >>> >>>>>>>>> > ... >>> >>>>>>>>> > @Id >>> >>>>>>>>> > @GeneratedValue(generator = "system-uuid") >>> >>>>>>>>> > @GenericGenerator(name = "system-uuid", strategy = >>> "uuid") >>> >>>>>>>>> > private String id_CTop; >>> >>>>>>>>> > } >>> >>>>>>>>> > >>> >>>>>>>>> > @Entity >>> >>>>>>>>> > @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) >>> >>>>>>>>> > abstract class CThing { >>> >>>>>>>>> > ... >>> >>>>>>>>> > @Id >>> >>>>>>>>> > @GeneratedValue(generator = "system-uuid") >>> >>>>>>>>> > @GenericGenerator(name = "system-uuid", strategy = >>> "uuid") >>> >>>>>>>>> > private String id_CThing; >>> >>>>>>>>> > } >>> >>>>>>>>> > >>> >>>>>>>>> > @Entity >>> >>>>>>>>> > @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) >>> >>>>>>>>> > @Table(name = "C2_table", catalog = "mydb_production", >>> >>>>>>>>> > uniqueConstraints = { >>> >>>>>>>>> > @UniqueConstraint(columnNames = "uuid") }) >>> >>>>>>>>> > class C2 extends CTop { >>> >>>>>>>>> > CThing thing; >>> >>>>>>>>> > ... >>> >>>>>>>>> > @OneToOne >>> >>>>>>>>> > @JoinColumn >>> >>>>>>>>> > public CThing getThing() { >>> >>>>>>>>> > return this.thing; >>> >>>>>>>>> > } >>> >>>>>>>>> > public void setThing( CThing thing ) { >>> >>>>>>>>> > this.thing = thing; >>> >>>>>>>>> > } >>> >>>>>>>>> > >>> >>>>>>>>> > @Column(name = "uuid", unique = false, nullable = true, >>> insertable >>> >>>>>>>>> > = true, >>> >>>>>>>>> > updatable = true) >>> >>>>>>>>> > public String getUuid() { >>> >>>>>>>>> > return this.uuid; >>> >>>>>>>>> > } >>> >>>>>>>>> > >>> >>>>>>>>> > public void setUuid(String uuid) { >>> >>>>>>>>> > this.uuid = uuid; >>> >>>>>>>>> > } >>> >>>>>>>>> > >>> >>>>>>>>> > @Id >>> >>>>>>>>> > @GeneratedValue(generator = "system-uuid") >>> >>>>>>>>> > @GenericGenerator(name = "system-uuid", strategy = >>> "uuid") >>> >>>>>>>>> > @Column(name = "id", unique = false, nullable = true, >>> >>>>>>>>> > insertable = true, >>> >>>>>>>>> > updatable = true) >>> >>>>>>>>> > public String getId() { >>> >>>>>>>>> > return this.id; >>> >>>>>>>>> > } >>> >>>>>>>>> > >>> >>>>>>>>> > } >>> >>>>>>>>> > >>> >>>>>>>>> > @Entity >>> >>>>>>>>> > @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) >>> >>>>>>>>> > @Table(name = "CThing1_table", catalog = "mydb_production", >>> >>>>>>>>> > uniqueConstraints = { @UniqueConstraint(columnNames = "uuid") >>> }) >>> >>>>>>>>> > class CThing1 extends CThing { >>> >>>>>>>>> > ... >>> >>>>>>>>> > // lots of ground type fields >>> >>>>>>>>> > >>> >>>>>>>>> > @Column(name = "uuid", unique = false, nullable = true, >>> insertable >>> >>>>>>>>> > = true, >>> >>>>>>>>> > updatable = true) >>> >>>>>>>>> > public String getUuid() { >>> >>>>>>>>> > return this.uuid; >>> >>>>>>>>> > } >>> >>>>>>>>> > >>> >>>>>>>>> > public void setUuid(String uuid) { >>> >>>>>>>>> > this.uuid = uuid; >>> >>>>>>>>> > } >>> >>>>>>>>> > >>> >>>>>>>>> > @Id >>> >>>>>>>>> > @GeneratedValue(generator = "system-uuid") >>> >>>>>>>>> > @GenericGenerator(name = "system-uuid", strategy = >>> "uuid") >>> >>>>>>>>> > @Column(name = "id", unique = false, nullable = true, >>> >>>>>>>>> > insertable = true, >>> >>>>>>>>> > updatable = true) >>> >>>>>>>>> > public String getId() { >>> >>>>>>>>> > return this.id; >>> >>>>>>>>> > } >>> >>>>>>>>> > >>> >>>>>>>>> > } >>> >>>>>>>>> > >>> >>>>>>>>> > >>> >>>>>>>>> > On Tue, Jun 16, 2009 at 1:45 PM, Derek Chen-Becker >>> >>>>>>>>> > <j...@chen-becker.org> >>> >>>>>>>>> > wrote: >>> >>>>>>>>> >> >>> >>>>>>>>> >> John Nilsson wrote: >>> >>>>>>>>> >> > Hi, >>> >>>>>>>>> >> > >>> >>>>>>>>> >> > I think the showSql property has been deprecated in favor >>> of >>> >>>>>>>>> >> > log4j >>> >>>>>>>>> >> > loggers. >>> >>>>>>>>> >> > >>> >>>>>>>>> >> > If you set the log4j level to TRACE for org.hibernate >>> you'll >>> >>>>>>>>> >> > get >>> >>>>>>>>> >> > everything Hibernate has to say about what it is doing. >>> Can't >>> >>>>>>>>> >> > remember >>> >>>>>>>>> >> > which one it is, but I know one of the loggers will give >>> you >>> >>>>>>>>> >> > the >>> >>>>>>>>> >> > values used in queries at the TRACE level. >>> >>>>>>>>> >> >>> >>>>>>>>> >> Good to know. Thanks! >>> >>>>>>>>> >> >>> >>>>>>>>> > >>> >>>>>>>>> > >>> >>>>>>>>> > >>> >>>>>>>>> > -- >>> >>>>>>>>> > L.G. Meredith >>> >>>>>>>>> > Managing Partner >>> >>>>>>>>> > Biosimilarity LLC >>> >>>>>>>>> > 1219 NW 83rd St >>> >>>>>>>>> > Seattle, WA 98117 >>> >>>>>>>>> > >>> >>>>>>>>> > +1 206.650.3740 >>> >>>>>>>>> > >>> >>>>>>>>> > http://biosimilarity.blogspot.com >>> >>>>>>>>> > >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> -- >>> >>>>>>>> L.G. Meredith >>> >>>>>>>> Managing Partner >>> >>>>>>>> Biosimilarity LLC >>> >>>>>>>> 1219 NW 83rd St >>> >>>>>>>> Seattle, WA 98117 >>> >>>>>>>> >>> >>>>>>>> +1 206.650.3740 >>> >>>>>>>> >>> >>>>>>>> http://biosimilarity.blogspot.com >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> -- >>> >>>>>>> L.G. Meredith >>> >>>>>>> Managing Partner >>> >>>>>>> Biosimilarity LLC >>> >>>>>>> 1219 NW 83rd St >>> >>>>>>> Seattle, WA 98117 >>> >>>>>>> >>> >>>>>>> +1 206.650.3740 >>> >>>>>>> >>> >>>>>>> http://biosimilarity.blogspot.com >>> >>>>>>> >>> >>>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> L.G. Meredith >>> >>>>> Managing Partner >>> >>>>> Biosimilarity LLC >>> >>>>> 1219 NW 83rd St >>> >>>>> Seattle, WA 98117 >>> >>>>> >>> >>>>> +1 206.650.3740 >>> >>>>> >>> >>>>> http://biosimilarity.blogspot.com >>> >>>>> >>> >>>>> >>> >>>> >>> >>> >>> >>> >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> L.G. Meredith >>> >> Managing Partner >>> >> Biosimilarity LLC >>> >> 1219 NW 83rd St >>> >> Seattle, WA 98117 >>> >> >>> >> +1 206.650.3740 >>> >> >>> >> http://biosimilarity.blogspot.com >>> >> >>> >> >> >>> >> >>> > >>> >>> >>> >> >> >> -- >> L.G. Meredith >> Managing Partner >> Biosimilarity LLC >> 1219 NW 83rd St >> Seattle, WA 98117 >> >> +1 206.650.3740 >> >> http://biosimilarity.blogspot.com >> >> >> > > > > -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
