Hi Luigi, So far, I'm missing getDirtyFields() which would be pretty useful in general I think.
The other thing I noticed is that there are still some ODocument remnants that require ODocument use by the client code. 1) When extending ODocumentHookAbstract 2) When running OSQLAsynchQuery and OSQLNonBlockingQuery (see https://github.com/orientechnologies/orientdb/issues/8019) Thanks, Harish. On Tuesday, January 30, 2018 at 3:07:44 AM UTC-8, Luigi Dell'Aquila wrote: > > Hi Harish, > > Good point, there is a chance that some methods that we did not expose on > the public interface are indeed useful as public API. > Please let us know which methods you need, we are open to evaluate them > > Thanks > > Luigi > > 2018-01-25 20:19 GMT+01:00 Harish <[email protected] <javascript:>>: > >> In the Orient 3.x user guide, we have the following guideline: >> >> >> *Attention: until v 2.2 the Document API relied on ODocument class only. >> ODocument is still there as the main implementation of OElement, but please >> don't use it directly, always use OElement instead* >> This is fine for most scenarios - but what about methods that cannot be >> reached through OElement? In such cases, is it OK to still cast to >> ODocument in 3.x? A simple case where this applies is the getDirtyFields() >> method on ODocument. >> >> >> Thanks, >> Harish. >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OrientDB" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
