Will OJB require db migration?

[Warwick Burrows <wa...@e2open.com>]

Carlos, will the new OBJ store implementation require that we migrate
our Slide 2.1 databases (ouch!) or will the schema generated by OJB
match the existing schema for our DBs?  We will shortly release our
current product on Slide 2.1 with many, many thousands of files. We plan
to release our next product on Slide 2.2.

Thanks,
Warwick


> -----Original Message-----
> From: Carlos Villegas [mailto:cav@uniscope.jp] 
> Sent: Thursday, February 10, 2005 7:59 PM
> To: Slide Users Mailing List
> Subject: Re: max revision limit?
> 
> 
> Yes, I implemented the proposed solution in the new OJB store 
> available 
> from CVS head. The OJB store is meant to replace the RDBMS stores but 
> it's not finished yet, the content store bit is not done. If 
> you want to 
> test it and verify that solves the problem, you can combine 
> it with the 
> txfile store, for instance: use txfile for content and OJB 
> for the rest, 
> a sample Domain.xml file is available in src/conf/ojb. The database 
> schema of the OJB store is not exactly the same as the current RDBMS 
> stores so part of the work is to write some migration tool as 
> well. That 
> needs to be done also.
> 
> I'll be working on finishing the OJB content store implementation but 
> progress is slow since I have a very busy schedule at work right now.
> 
> Carlos
> 
> Luke Noel-Storr wrote:
> > Hi,
> > 
> > I was just wondering if you'd made any progress with this?
> > 
> > I've come up against this problem again now we are using a database
> > backed version of Slide again, and it would be great if a 
> solution was 
> > in the pipeline.
> > 
> > It's certainly a design flaw as it is, and I can no longer make the
> > fields in my database bigger (which just puts off the 
> problem anyway) 
> > without changing them to blobs (which will also require a 
> code change).
> > 
> > 
> > Cheers
> > 
> > Luke.
> > -----
> > 
> > 
> > 
> > Carlos Villegas wrote:
> > 
> >> Ok. I'll work on it. I'm quite busy at work but I'll make some time
> >> for this.
> >>
> >> Carlos
> >>
> >> James Mason wrote:
> >>
> >>> Carlos,
> >>>
> >>> This seems valuable to me as well. Multivalue properties 
> are a bit 
> >>> of
> >>> a pain to work with right now.
> >>>
> >>> -James
> >>>
> >>> Warwick Burrows wrote:
> >>>
> >>>> Hi Carlos,
> >>>>
> >>>> I definitely think its worth it. How were you thinking 
> of indexing 
> >>>> this second table? The way to uniquely identify any individual 
> >>>> property in the property table seems to require 3 fields -- 
> >>>> property namespace, property
> >>>> name and version id? That would indicate that any table 
> you create 
> >>>> would
> >>>> need all three of these as the primary key?
> >>>>
> >>>> Warwick
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Carlos Villegas [mailto:cav@uniscope.jp] Sent: Tuesday,
> >>>> September 07, 2004 8:40 PM
> >>>> To: Slide Users Mailing List
> >>>> Subject: Re: max revision limit?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Warwick Burrows wrote:
> >>>>
> >>>>> Yes, but how much bigger? :-) It seems to be a flaw in 
> the design
> >>>>> that there is a version property that constantly grows 
> in length 
> >>>>> with each new version added. Is this the way the spec 
> defined the 
> >>>>> value of this property, or is this just Slide's implementation?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> It seems to me it's a design flaw.
> >>>>
> >>>> There are several properties that are a list of values 
> like history 
> >>>> and group-member-set. I was thinking of adding a type identifier 
> >>>> field to the properties table and storing the individual 
> values in 
> >>>> a different table, one
> >>>> per row. That's the usual relational db solution to this problem.
> >>>>
> >>>> BTW, there's a property_type field in the properties 
> table and the 
> >>>> Java object also has this field, but it doesn't seem to 
> be used. Is 
> >>>> it used at all? If is not can we use it for this purpose?
> >>>>
> >>>> I volunteer to try to fix at least one of the database 
> stores using
> >>>> this
> >>>> technique if anybody thinks it's worth it.
> >>>>
> >>>> Carlos
> >>>>
> >>>> 
> -------------------------------------------------------------------
> >>>> --
> >>>> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail: 
> slide-user-help@jakarta.apache.org
> >>>>
> >>>> 
> -------------------------------------------------------------------
> >>>> --
> >>>> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail: 
> slide-user-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>> 
> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: 
> slide-user-help@jakarta.apache.org
> >>>
> >>>
> >>
> >> 
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: slide-user-help@jakarta.apache.org
> >>
> >>
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-user-help@jakarta.apache.org
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org