[MAGNOLIA-340] core.search package, extend QueryResult and fix NodeData Created: 21/Apr/05  Updated: 11/Mar/08  Resolved: 27/Apr/05

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 2.1 Final
Fix Version/s: 2.1 Final

Type: Task Priority: Blocker
Reporter: Sameer Charles Assignee: Sameer Charles
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:

 Description   

magnolia NodeData is stored as nt:file type in jcr, that worked quite well but its a problem with simple SQL queries
like select * from nt:unstructured where title='home' this will fail because there is no property called "title" instead its stored
as title/jcr:content/Data

  • fix NodeData so its a leaf in a jcr hierarchy.
  • extend QueryResult such that it filters on required node type


 Comments   
Comment by Sameer Charles [ 22/Apr/05 ]

next steps :

1. refactor NodeData class so its no longer content type mgnl:nodeData but a simple jcr property

  • this will help in reducing number of nodes creating
  • jcr search query will work as expected

2. ContentNode will be depricated since it does not make sence to have wraper classes for nodes when we have a
possibility to use NodeTypes

3. Define QueryResult interface, implement core.search package

4. Refoctoring all effected classes.

I am working on it, expecting to finish early next week. ll update bootstrap and new node type definitions once tested.

Devs : please let me know if someone else also working on magnolia.core package, if yes ll wait unitil you finish.

Comment by Sameer Charles [ 25/Apr/05 ]

just commited few changes on svn

http://svn.magnolia.info/svn/magnolia/trunk/src/main/info/magnolia/cms/core/*
http://svn.magnolia.info/svn/magnolia/trunk/src/main/info/magnolia/cms/beans/config/ContentRepository.java
http://svn.magnolia.info/svn/magnolia/trunk/src/webapp/WEB-INF/bootstrap/*
http://svn.magnolia.info/svn/magnolia/trunk/src/webapp/repositories/*

Note : you will see all jcr system properties in tree view, I am working on it to filter.

you can see the performance difference on persisting data, its 10x faster also for activation

Next task :
Now ll be working on refactoring ContentNode/usage, for this I might have to touch almost all packages

keep you posted

Comment by Fabrizio Giustina [ 25/Apr/05 ]

Well done Sameer, looks a lot faster and simpler now...

just a few comments:

  • the default xml for the website repository still contains references to mgnl:nodeData and need to be fixed
  • how can you convert content to the new format? Activation? Do you have anything (xslt) that can be used to directly update an xml file?
  • I just modified the BootStrapTest in order to use the content in the standard bootstrap dir: I recommend to always run this test and keep it updated (e.g. changed nodetypes)... it's the easier way to see if everything works (you can add any assertion on imported content if needed)
Comment by Sameer Charles [ 25/Apr/05 ]

updated/tested search QueryResult
http://svn.magnolia.info/svn/magnolia/trunk/src/main/info/magnolia/cms/core/search/*
queries should work as defined in specs
http://svn.magnolia.info/svn/magnolia/trunk/src/webapp/templates/jsp/samples/search/search.jsp

--------

  • the default xml for the website repository still contains references to mgnl:nodeData and need to be fixed
    just noticed , will fix it
  • how can you convert content to the new format? Activation? Do you have anything (xslt) that can be used to directly update an xml file?
    I did it via Activation.
  • I just modified the BootStrapTest in order to use the content in the standard bootstrap dir: I recommend to always run this test and keep it updated (e.g. changed nodetypes)... it's the easier way to see if everything works (you can add any assertion on imported content if needed)

yeah my mistake, will do so.

--------

Next Steps :
as mentioned, remove dependencies on ContentNode class, instead use Content. treat contentNode as any other custom NodeType.

Comment by Sameer Charles [ 25/Apr/05 ]

website.features.xml updated

Comment by Fabrizio Giustina [ 25/Apr/05 ]

tested, everything works for me and bootstrap is faster than before.

There is something wrong with export/import of binary properties however, don't know if this is a problem of magnolia or a jackrabbit... could you give it a look?
If you try exporting a page which contains an image and reimporting it (from http://localhost:8080/magnolia/export) the image is then handled as a text property (the binary content is displayed instead of the name when using <cms:out>).

Comment by Sameer Charles [ 25/Apr/05 ]

hmmm its a same problem with all other types, XML export does not maintain data type information ! strange
when you import it all properties (binary, boolean, long..) are read as strings, except jcr:* properties.

seems like on document view import it uses "PropertyDefinition" as defined in NodeType definition to determine the data type of a property, and since magnolia nodetype definition defines a generic property "*" it does not know how to handle this.

I am not sure if its a jackrabbit problem or magnolia
ll work on it!

Comment by Sameer Charles [ 26/Apr/05 ]

its a problem with jackrabbit, since jcr does not define any structure for xml export its open for the implementation.
we define preperty as "undefined" and on save its saved properly.

snippet from the specs----

""

Comment by Sameer Charles [ 26/Apr/05 ]

"

Comment by Sameer Charles [ 26/Apr/05 ]

Returns the type of this Property. The type returned
is that which was set at property creation. Note that
for some property p, the type returned by
p.getType() may differ from the type returned by
p.getDefinition.getRequiredType() only in the
case where the latter returns UNDEFINED. The type of
a property instance is never UNDEFINED (it must
always have some actual type). See 6.2.5 Property
Types and 6.7.18 Discovery of Constraints on Existing
Items.
--------------------------------------------------
int UNDEFINED
This constant can be used within a property definition (see
6.7.6 Property Definitions) to specify that the property in
question may be of any type. However, it cannot be the
actual type of any property instance. For example it will
never be returned by Property.getType and (in level 2
implementations) it cannot be assigned as the type when
creating a new property.

Comment by Fabrizio Giustina [ 26/Apr/05 ]

reported to jackrabbit

http://issues.apache.org/jira/browse/JCR-115

Comment by Fabrizio Giustina [ 26/Apr/05 ]

see comments on http://issues.apache.org/jira/browse/JCR-115
modified exportServlet to use system view for the website repository and document view for others. Everything works fine also for import and export, you can go on with refactoring now

Comment by Sameer Charles [ 26/Apr/05 ]

great!!

opened new JIRA issue http://jira.magnolia.info/browse/MAGNOLIA-351

Comment by Sameer Charles [ 27/Apr/05 ]

follow http://jira.magnolia.info/browse/MAGNOLIA-351

Generated at Mon Feb 12 03:16:27 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.