Hi John,
The RIFE/Crud Getting started page
(http://rifers.org/wiki/display/RIFECRUD/Getting+started) states:
"...[Automatic table creation] is not mandatory and that RIFE's
persistence
layer can map the properties to existing tables."
How do you do that?
The key is that the CRUD site structure processor needs to be
registered and known. This is done in the static initializer of the
CreateCrudStructureParticipant (https://svn.rifers.org/rife-crud/
trunk/src/java/com/uwyn/rife/rep/participants/
CreateCrudStructureParticipant.java). You can just add this to your
own participant. Feel free to add this info to the wiki.
If I take out the CreateCrudStructureParticipant participant, I get
a message
that says:
The site 'crud:com.tx.app.data.MyData' declares an unsupported site
processor
identifier 'crud'. Since I am using Derby at the moment, I have
the option of
just blowing away the files. But it won't always be so.
Another small issue, I have a byte [] property called thumbnail, to
which I
apply:
addConstraint(new ConstrainedProperty("thumbnail")
.notNull(true)
.file(true)
.listed(true)
.mimeType(MimeType.IMAGE_JPEG)
.contentAttribute("width", 150));
...But CRUD doesn't seem to understand that this is a file upload,
I just get
a text field. Is there something else I need to add?
This is very strange, the only thing need to get the file upload
field in a RIFE/Crud form is the file(true) constraint. Can you try
to isolate this and send me the code so that I can investigate?
On another note, I saw in previous posts where you were trying to
figure out
how to handle schema changes. Have you thought about mimiking the
ActiveRecord Migration idea:
http://wiki.rubyonrails.com/rails/pages/UsingMigrations ?
I'm sure you have, just thought I would throw it out there.
Indeed I was hoping to go that route. The main issue that I have an
acute lack of time to really take care of that. If anybody feels to
call to implement this, I'm sure it will be a popular feature, I get
many requests for it.
MetaData classes could have migrateForward/migrateBackward methods
which
contain only the most recent deltas. And some constraint-like
mechanism could
Very interesting approach, I hadn't though of using the MetaData
merging for this. I like it! Maybe it's possible to have all the
changes in there by returning a collection of MigrationOperation
classes from the migrateForward/migrateBackward methods. These can
then be inner classes and just stay present.
define the table changes. For this to be effective, you'd have to
be using
The main missing part is the lack of an AlterTable query builder, as
well as CreateIndex and DropIndex. The first step to schema
migrations is the presence of these. They should not be difficult to
implement at all, just some time is needed. The other query builders
are good examples of how to do it.
version control, and probably tagging for every schema change.
Backing up
would be painful, but mostly we'd be moving forward. There is also
the issue
of deciding when/how to run the migrations, the RAILs approach is
manual.
Maybe have a way of checking the meta data against the database, and
attempting migrateForward is a difference is detected?
I have already added something like that to RIFE/Crud. It records the
last modification time of a CRUD bean class file using the Java
preferences API. It just isn't used for any checking. The plan was to
use it for doing these automatic migrations.
Best regards,
Geert
--
Geert Bevin
Uwyn bvba "Use what you need"
http://www.uwyn.com
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
