Re: XML_Indexing and DB_Dataobject

Justin Patrin wrote:

Are you talking about a whole new "Data Driver" layer ? No, I don't think this is a good idea, but anyway that is Alan Knowles to decide. I don't know the DB_Dataobject code enough to say how to implement XML containers.

You say you don't want a data driver, but you still want to use DataObject with XML? Ir do you mean making an XML_DataObject?

XML_DataObject's not a bad idea. The only requirement would be that DB_DO and XML_DO work together to provide the same interface. So that, one could have :

    class DataObject_Pets extends DataObjectCore

Then one could either load a, say, 'DataObjectCore.xml.php' file containing :

    class DataObjectCore extends XML_DataObject

or a 'DataObjectCore.db.php' with :

    class DataObjectCore extends DB_DataObject

This looks like a driver layer : but it would be the responsibility of the app developper.

IMHO if you want to store data in XML, it's much more useful to make a DB driver which stores its data in XML. It can even just support a subset of SQL if you want. This way, it takes no change to DB_DataObject and other DB-using projects could make use of it with minimal changes.

Well, SQL parsing is heavy... I recognize a DB XML driver is a nice idea. If it's just a small subset, then it may be acceptable, yes. Thanks for this idea :-) But, what I like about Dataobjects is that they sufficiently abstract the database, so that you interact with it using methods (find(), etc...). No need to parse SQL, no overhead. With a such interface, in theory you can use whatever data container you wish.

Sure, but DB_DataObject is currently highly tied to DB, hence its name. It's also highly tied to SQL. A new DataObject could be made with a data driver backend to support either way, but, as we both have said, this would be overkill. If you want to make an XML_DataObject, I don't think anyone would mind.

Okay, let me recapitulate : 1 - a DB XML driver, which would indirectly XML-enable DB_DataObject, and

    could be useful to all DB users

2 - a driver layer inside DB_DataoObject : you seem to say this is irrelevant

    because DO is meant to be tightly integrated with DB ; actually Alan Knowles
    has started to implement that in the dbdo c extension

3 - an XML_DataObject package, with the same interface as DB_DataObject 4 - a versatile DataObject featuring an abstract data driver layer, which

    could either use its own drivers (XML, etc..) or fallback on DB_DO

Solution 1 would be more universal, but slow. Solution 3, if well done, with proper indexing, could be blazingly fast IMHO. But, if the dbdo c extension already support xml, then all that may be redundant, except for indexing, which dbdo (c extension) does not seem to support. Additionally, not everyone can load custom extensions. -- og