Upgrade 2024 API causing schema error

[ptranU2KHX]

Hi everyone,

Hope you all are doing great.

Recently, I upgraded the revit library with the lastest version 2024.

Since then, I got the error 'different schema with same identity...' although I do not change the schema structure or add new schema with the same id. 

I doubted about the ElementId class as it is one of the changes in the API.

Please help. Thank you in advance.

[moturi.magati.george]

Hi @ptranU2KHX,

There was a response by @RPTHOMAS108 in a different question on this forum. Hope it helps you explain the error you have.

https://forums.autodesk.com/t5/revit-api-forum/a-different-schema-with-the-same-identity-already-exi...

[ptranU2KHX]

Hi @moturi.magati.george , thank you for your reply.

As I mentioned above, I did not change the schema structure or anything inside. It just happened to me after I upgrading Revit API 2024.

I overcome this issue by having a check before the SchemaBuilder.

[RPTHOMAS108]

Strange error I would not expect to be getting that purely for an upgrade however you should always look for an existing schema before creating one in my view.

Perhaps clarify if you didn't have the same issue on previous upgrade from 2022 to 2023.

Note that you have used a different schema id in your second post compared to first and are now looking for that 'new' one, so I assume you would not find that to be existing in the document anyway (apart from this day onwards)? You solved the problem by creating a new schema but the real question remains should an upgrade alone cause this issue? You should probably continue with the question and gain clarification on if the existing schemas retrieved from upgraded documents support Int64 ElementIds etc. 

I think the support on existing schemas for ElementIds of Int64 is easy to test however.

[ptranU2KHX]

Hi @RPTHOMAS108 

I did not have the same issue on previous upgrade from 2022 to 2023. The second post is the same schema with same id, I just add a check before the other process.

This schema I already created from 2022 and since then, it worked fine. I even did not check the exisiting schema first before creating new one, but it worked. The figure below is my schema since 2022.

If I created a completely new project in Revit 2024, this schema above worked fine but not for an old one in Revit 2023.

[RPTHOMAS108]

Sounds then like you should test upgrading a 2023 file with ElementId extensible storage field (finding schema by id not creating it) and then trying to store a Int64 ElementId.

Sounds like by retrieving the 2023 schema the internal structure may be seen as different due to the ElementId change. So I would therefore like to see what happens if you try setting it with a Long ElementId. Otherwise there may be issues when Int64s are encountered later (if this is an issue).

I still don't know what the Long ElementIds will be used for in the grand scheme of things i.e. if the Autodesk expect to encounter a model with so many elements that Int32 capacity is not enough or if they want to use them for more descriptive bit flags etc. (the former seems unlikely). The latter could occur at any moment, if that is the motivation.

I also wonder about the form of the UniqueId, I assume that last part may get longer to allow for Int64? Then again they might say we are not using -ve values for ElementIds in UniqueIds so can still assume UInt32 up to 0xFFFFFFFF.

Also interesting that your GUID starts with a 'K' why is that?

[ptranU2KHX]

Sorry but do you know any type of element with Int64 ElementId? I am a newbie with Revit.

The schema I used to store wall element id. I am not sure if this is Int64 ElementId or not.

Thank you.

[RPTHOMAS108]

You can create one in Revit 2024 e.g. try:

Int64 LongId = Int32.MaxValue + 1;

ElementId LongEID = New ElementId(LongId);

Then you can then try setting the existing field value with LongEID.

[ricaun]

I have this old example with some implementation with a simple storage a field factory class: https://github.com/ricaun-io/RevitAddin.StorageExample

In the end, the best approach I found is to convert the data to a string using JSON, and save that in a simple schema with only a string. The Revit schema never changes, the only thing that you need to worry about is serializing/deserializing the ElementId.

I have this implementation of a converter:
https://github.com/ricaun-io/ricaun.Revit.ExtensibleJson/blob/master/ricaun.Revit.ExtensibleJson/Con...

Still need to update to work with Revit2024+.

[RPTHOMAS108]

Just to close this out I found the following behaviour:

• No issue putting an Int64 ElementId into a schema created in 2023 and upgraded.
• Although you can store an ElementId that doesn't represent an item in Revit such a field will be reset to -1 upon reopening the document (I guess that is by design since it doesn't point to anything useful).

I agree with @ricaun 9/10 it is easier to serialise a string into a single field I would generally do this for add-in settings. However as also noted if you want to store relationships between elements then best to use ElementId extensible storage fields.

I'm not using C# so not sure how you were able to create a GUID with a 'K' in it, I suspect you may have ended up with an empty GUID somehow perhaps (generally you should get a format exception if non hexadecimal/hyphen characters used).

The change to Int64 should be transparent for most situations there is a design decision some develops will need to consider in terms of how ElementId.IntegerValue is replaced with ElementId.Value. I decided it was better to update backwards the base code with extension method ElementId.Value. Can't do much about the constructor however:

Module RT_ElementIdExtensionModule

#If RvtVer >= 2024 Then
    <Extension>
    Public Function NewElementId(L As Long) As ElementId
        Return New ElementId(L)
    End Function
#Else
     <Extension>
    Public Function Value(ID As ElementId) As Long
        Return ID.IntegerValue
    End Function
    <Extension>
    Public Function NewElementId(L As Long) As ElementId
        If L > Int32.MaxValue OrElse L < Int32.MinValue Then
            Throw New OverflowException("Value for ElementId out of range.")
        End If
        Return New ElementId(CInt(L))
    End Function
#End If

End Module

[GaryOrrMBI]

I know that I'm talking to people that are way over my head in API knowledge here but I feel a need to add a thought.

Since the concept of creating a new schema using a string has already been tossed out there, instead of serializing the ElementId into a string, wouldn't it be safer to simply use the UniqueId which is already a string and, per the API help, is actually a more stable method of acquiring an Element?

From Help on ElementId:
However ids are subject to change during an Autodesk Revit session and as such should not be retained and used across repeated calls to external commands.

From Help on UniqueId:
The UniqueId can be used to store an identifier in an external database and to retrieve the same element in the future if it still exists. This id can be passed to the Document's Element property to retrieve the element. The UniqueId is stable across upgrades and workset operations such as Save To Central, while the ElementId property may change.

Just a thought

-G

[renencon]

Some thoughts with regard to this issue.

I use extensible storage and use specific schemas to save ElementIds in a document and have encountered the same issue as described by @ptranU2KHX.

I am not sure if this should be escalated to the Revit Development team.

So, if you have created and maintained schemas in Revit releases prior to 2024, ElementId field data would be stored in a document in the Int32 format.

However, Revit 2024 introduced the ElementId Int64 data structure and the Int32 format is now obsolete.

Shouldn’t Revit 2024 during the upgrade process of a document created in a previous version also upgrade all ElementIds to the new Int64 format?

That would make it a lot easier for developers.

The alternative approach is for a developer to create new Schemas with new GUIDs for basically the same schema structure and upgrade all add-in specific data to the new 2024 schemas.

I am not sure why the development team has taken this approach.

I hope the above makes sense.

[ricaun]

I was making some tests to update a file to version 2024 that has a schema and data with ElementId.

First when I was testing the upgrade process was showing a popup to update the schema or something, and in the end, my data in the ProjectInfo was failing, I was losing all the data of the extensible store.

I don't know what changed but now I can't replicate the issue. Is working normally, the project is updated, and the data with an ElementId with the BuiltInCategory.OST_GenericModel or -2000151.

I have some code built in Revit 2024 to read that data and works fine.

Here is the file if anyone what's to update and take a look.

Edited: This is the popup:

[renencon]

This is an interesting one @ricaun and suggests that there might be a bug with the Revit 2024 document upgrade code of previous document versions that relates to the new 64-bit ElementId class.

Let me try and describe a scenario, in the steps below, that can be replicated and highlights the issue.

1. Create a schema of any kind of structure that uses ElementId field data in a version prior to Revit 2024.
2. Use the newly created schema and save ElementId field data in a document in a version prior to Revit 2024. Please note that ElementId data do not necessarily originate from the New ElementId constructor as suggested by @RPTHOMAS108 in this discussion.
3. Save the document in the version prior to Revit 2024.
4. Rebuild the add-in that uses the same schema structure with the same GUID in Revit 2024.
5. Start Revit 2024 and open the previously created document. Revit upgrades the document with no issues at all. So, it seems!
6. However, if instead of step 5 above you proceed and create a new document, and the new schema in Revit 2024, that schema would now reside in memory, and if you try the previous step 5 you will receive the “Schema Conflict when Loading a File” error dialogue.

Interesting even further …

Following step 5 above in Revit 2024 the schema will automatically be created and will reside in memory. You will therefore use Schema Lookup to find it and use it to create extensible data in a new document and guess what, it works that way in the new document. However, the reversible process 1-6 described above fails with the schema conflict dialogue.

@moturi.magati.george, could you help here, please? I hope the above makes sense unless I have missed something.

Could we escalate this to the Development Team?

Thank you.

Anastasios

[moturi.magati.george]

Hi @ptranU2KHX and @renencon,

I have asked the development team for you here. I will update with the response they will provide.

[RPTHOMAS108]

@moturi.magati.george I've been looking at this further and I think there is an issue that the team should also be made aware of, I've enclosed eStorage2024upgrade_MRC.zip containing:

RPT_RvtMRC

StepsToReproduce.xlsx

Relevant Revit files used in MRC.

I'd like to draw your attention especially to 'Test C' as it is critical for elements containing existing schemas that are upgraded whilst new schema exists in memory.

C	Open Revit
C	Open document named 2024_SelfStore.rvt
C	#Run Current MRC >  Select stored element	OK
C	Open document named 2023_SelfStore.rvt	Wall is deleted during upgrade!!!
*Seems element with 'old 2023' schema was removed upon upgrade if 'new 2024' one exists in memory

It should be noted that the underlying issue related to the error message other people are experiencing above is that the existing schema should be found in memory and not remade each time (if the schema exists in memory use it don't make it). 

However I note that the upgrade process is deleting elements that have the old schema if new one exists in memory first.

When I say old vs new schema here I'm referring to exactly the same schema with the only difference being the ElementId field was made previously with Int32 not Int64. 

[moturi.magati.george]

Hi @RPTHOMAS108,

Thank you for taking your time to replicate and point out this issue. The information provided will guide the team in coming up with a solution. I have escalated the issue as a bug REVIT-207846. I will share the updates as soon as it is responded to

NOTE: Same issue was logged as a bug under ticket REVIT-205801

[RPTHOMAS108]

Thanks @moturi.magati.george 

Here is where it goes wrong in journal I believe, an achieve error of the too small blob kind it seems (8 expected instead got 4 perhaps)?

The id noted is that of the wall.

Also to replicate all you really have to do is upgrade a project containing the Int32 ElementId field when there is already the new version with the Int64 one in memory.

'E 31-May-2023 13:13:20.906; 7:<
' [Jrn.ESSchemaOpenRoster] 1Rvt.Attr.StoredSchemas: Test 2003a3e1-270a-4ef1-958a-481778264904
'E 31-May-2023 13:13:20.906; 7:<
' [Jrn.ForgeSchemaOpenRoster] 880
' 6:< ::88:: Delta VM: Avail -2 -> 134178048 MB, Used +4 -> 691 MB, Peak +3 -> 691 MB; RAM: Avail -11 -> 21765 MB, Used +5 -> 794 MB, Peak +5 -> 794 MB
' 6:< GUI Resource Usage GDI: Avail 8569, Used 1431, User: Used 586
' 6:< File was saved in Autodesk Revit 2024 (Build: 20230308_1635(x64))
'C 31-May-2023 13:13:20.936; An ArchiveException 105 is raised at line 545 of E:\Ship\2024_px64\Source\Foundation\Utility\Archive\AArcObj.cpp: file is too short to read blob with size=8
'C 31-May-2023 13:13:20.998; Loaded elemStream#1: uncompSize=1189681, compSize=154477, count=2307
'C 31-May-2023 13:13:20.998; LoadLatestEpoch::loadLatestEpoch 0x00000000000=thelper.currentPos() 0x00000025b6d=thelper.targetPos()
' 0.110626 8:<<loadLatestVersion
'C 31-May-2023 13:13:21.029; FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: removing missing elements on load
'C 31-May-2023 13:13:21.029; FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: missing elem 2748=id (0 1 1=dates)
'C 31-May-2023 13:13:21.029; FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: 1 missing elements are removed

[moturi.magati.george]

Hi @RPTHOMAS108,

Thank you for sharing more information on this. I have also shared with them the link to this thread.
They should have all the information they need based on your findings.

[moturi.magati.george · Accepted solution]

Hi @ptranU2KHX, @RPTHOMAS108, @ricaun, @renencon, @GaryOrrMBI

The development team has acknowledged that there is a problem with the schema upgrade. They are working on the fix and they will update once it is ready.