Once I finish the content store bit and I have the full store working I'll revisit these issues. Schema compatibility wasn't my priority as long as I provided some migration tool, I thought. But I'll see if I can simplify the migration path by trying to eliminate the dump/restore requirenment.
Carlos
Warwick Burrows wrote:
Oops. I should have finished reading your email. The OJB changes will definitely require data migration then... What kind of changes are we talking about?
Thanks.
-----Original Message-----
From: Warwick Burrows Sent: Thursday, February 10, 2005 8:03 PM
To: Slide Users Mailing List
Subject: Will OJB require db migration?
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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-------------------------------------------------------------------
--
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
