McAdmin

Administrators
  • Content count

    245
  • Joined

  • Last visited

Community Reputation

0 Neutral

About McAdmin

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  1. File SpatialIndex.Rn.cs is available in the package. But it was not included in Visual Studio projects (an oversight). We do not use Visual Studio projects to build Perst libraries - we prefer makefiles that can easily build all configurations. Just adding the file to the project should solve the problem. The next release of Perst will address this oversight.
  2. Per the email reply to you: Perst uses bitmaps for active and shadow pages. Upon transaction commit, the bitmaps’ roles are changed (shadow becomes active, active becomes shadow for the next transaction). That is all. Perst is open source. Source code is the ultimate technical documentation.
  3. If I correctly understand your code, you are measuring time of extracting one single object from the database and, in case of Perst with a "cold" cache, it takes about 300 msec vs. about 10 msec for SQLite. There are several possible explanations: 1. Perst is loading not just the single object, but all referenced objects. If your class contains references, array of references or some other kind(s) of collections of references to other objects, then Perst will recursively load all referenced objects. 2. Perst is accessing the object through an extra level of indirection (object index). Pages of this object index also have to be loaded in memory. Usually they are kept in the cache, but at startup Perst will have to read them. 3. I don't know what type and number of indexes are used in Perst versus SQLite. It also can have an influence on load time. Please also note that measuring the time of such a short query is not reliable - the error can be vey large. First of all, it is comparable to the resolution of the system timer. Second, the background activity on the device, or even in the application (like garbage collection), can have a significant impact on query execution time. Since SQLite is implemented in C, and Perst is implemented in Java/.Net, the probability of initiating garbage collection in the case of Perst is much higher.
  4. Thank you for reporting and explaining the problem. We had not faced this covariance problem before so it took some time to understan it. The lookup method will be changed in the following way: static Method lookupMethod(Class cls, String ident, Class[] profile) { Method m = null; for (Class scope = cls; scope != null; scope = scope.getSuperclass()) { try { m = scope.getDeclaredMethod(ident, profile); if (m.isBridge()) { Method[] methods = scope.getDeclaredMethods(); for (Method method : methods) { if (method.getName() == ident && Arrays.equals(method.getParameterTypes(), profile) && !method.isBridge()) { m = method; break; } } Assert.that(!m.isBridge()); } break; } catch(Exception x) {} } if (m == null && profile.length == 0) { ident = "get" + Character.toUpperCase(ident.charAt(0)) + ident.substring(1); for (Class scope = cls; scope != null; scope = scope.getSuperclass()) { try { m = scope.getDeclaredMethod(ident, profile); if (m.isBridge()) { Method[] methods = scope.getDeclaredMethods(); for (Method method : methods) { if (method.getName() == ident && method.getParameterTypes().length == 0 && !method.isBridge()) { m = method; break; } } Assert.that(!m.isBridge()); } break; } catch(Exception x) {} } } if (m != null) { try { m.setAccessible(true); } catch(Exception x) {} } return m; }
  5. You can completely drop the full text index. To do it, you need access to the instance of this index. Unfortunately, right now it is not possible - the class Metatable where it is located is an internal class for the Perst namespace and it cannot be accessed from outside. In the next version of Perst we will add a method to the Database class allowing to get the instance of FullTextIndex. Right now, you can add this method yourself in the Database.cs class: /// <summary> /// Get full text index /// </summary> /// <returns>used full text index</returns> public FullTextIndex FullTextIndex { get { return metadata.fullTextIndex; } } Having the reference to FullTextIndex, you can invoke the Clear method to completely erase the full text index. But please note that even in this case the size of the database will not decrease - Perst never shrinks the size of a database file. This space just will be reused by Perst. The only way to reduce the size of the database file is to call Backup and then replace the database with the generated backup file. To avoid insertion of data in the full text index in the future, you should remove the [FullTextIndexable] attribute from all fields. If you do not want to completely drop the full text index, then you can remove [FullTextIndexable] from some fields and call the Database.UpdateFullTrxtIndex method for all object instances of the changed classes. But note that the dictionary of the full text index is also never reduced (except by the Clear method) - in other words, new words are added to the inverse index but never removed.
  6. Again, you need to populate a Perst database, then export the contents to XML, and look at the resulting XML document.
  7. Try this: var items4 = (from computerFileData in perstDB.GetTable<ComputerFileData>() select computerFileData).Skip(start).Take(numberofRecords); Int64 highestPathLenth4 = 0; foreach (var computerFileData in items4)
  8. We didn't say that it is not possible to import XLM files that were not created by XMLExport, we just said that it wasn't the intended usage of XMLExport/XMLImport. You can create the XML file yourself (i.e. generate it with some tool) but it must match the format that Perst expects. We haven't documented that (again, because we didn't expect it to be used in this way), so the easiest thing to do to get the required format is to let Perst generate some XML file for your database schema, then match the format. In any case you need the definitions of classes to work with a Perst database. Just write a simple program that will populate the database with instances of all classes you need to import (use some dummy data) and then use XMLExport to save in XML format. Then you can create an XML file with your real data matching this format. (If the XML is being generated by some other tool that doesn't give you control over how it formats XML, then you might need to use XSLT to massage the XML into the format that Perst requires.) Also, note that Perst requires OID to be specified for all objects. But they can be "logical" OIDs - just use natural number 1,2,3... as OIDs. When Perst imports data from the XML file it will establish mapping between these logical OIDs used in XML files and real OIDs assigned to created objects.
  9. IEnumerable.Skip and IEnumerable.Take are standard LINQ methods. The Perst LINQ adapter doesn't override them - so there is no special optimization in Perst for getting a subset of the result. But you can still use the Skip/Take methods - their default implementation will just iterate through specified number of records.
  10. Also, there is the Database.CountRecords methods which returns the number of records in a table. But if you want to get the number of records matching some particular search condition in manner similar to: select count(*) from T where x>0 then you should perform a normal select and then use the Enumerable.Count method (note that Enumerable is a Perst helper class - do not mix it up with the standard .Net IEnumerable interface).
  11. Parameter IDs are 1-based (as in JDBC and ODBC). So you should use q[1] instead of q[0]
  12. The query language supported by Perst is an object-oriented subset of SQL. The result of a query is always a set of object, not tuples; aggregate functions are not supported. If you want to get the max value of some field, you just need to perform a selection with an appropriate "order by" clause, for example: ComputerFileData cfd = Enumerable.First(perstDB.Select(typeof (ComputerFileData), "order by FileID desc")); if (cfd != null) { Console.out.WriteLine("MAX(FileID)=" + cfd.FileID); } Execution of the query above will be efficient (it will use the index and fetch only one record) if there is an index for the field FileID.
  13. Looks like there is some problem with accessing the transaction context. The mainstream version of Perst uses ThreadLocal which is not available in J2ME. So we need to use a normal Hashtable to maintain the thread-to-transaction_context mapping. The thread instance itself is used as a key. And according to the Java specification, the methods of the Hashtable class are synchronized: there should no be race condition if two different threads try to update the hash. But it looks like something is not working properly in your environment. Attached is a slightly changed version of the StorageImpl class (download it and rename it from .txt to java) that uses an explicit synchronized statement around access to this hash table. As noted, it should not be needed, since hash table methods are supposed to be synchronized. But, regardless, let's check if the problems are reproduced with this patch. If not - it means that for some reason the implementation of Hashtable class in your JVM is not thread safe. StorageImpl.txt
  14. OK, that is the reason for the problem. When a local variable (or parameter) is used in a LINQ query, the compiler passes it through a private class for which a field is assigned the value of this variable. The field is private and Sliverlight doesn't allow access to non-public components. Suggestion: create your own class with public _userLogin component, assign the value to it and do the same query in some method of this class
  15. When using the Perst reflection package for J2ME you need to generate pack/unpack methods using the provided SerGen utility (src11/util/SerGen.java) or write them manually. Have you done so? If so, can you send a complete definition of your A and B classes?